Most complaints about Git’s UI make sense, but even that’s not entirely as bad as people claim IMO because (like @enobayram said) there is inherent complexity here.
DVCS concepts are not valid complaints.
The Gitless project seems pretty nice, but I wish they’d kept the index and the name for log and only cleaned up snafus. Like how git tag lists tags, git branch lists branches and git stash, well… no.
Yes there is inherent complexity. But mercurial and darcs just to name two have both demonstrated that you can have a DVCS with a sane and above all safe UI.
gitless sounds nice except that something I do all the time is to start working on a change, then realise I was on the wrong branch, and move it to a different branch. With git I can do this with git stash -u && git checkout otherbranch && git stash pop which is a lot more work than it needs to be but does at least work. As far as I can tell under gitless I’d just be completely stuffed.
git stash -u && git checkout otherbranch && git stash pop
Tools that do complex things or are used frequently have different requirements than tools that are simple or are used infrequently. For a simple example, you want a banking app on your phone to be as simple and follow ios/android guidelines as to be as intuitive as possible, since you’re probably not doing anything complex in it, and you’re touching it maybe a couple of times per month, so learning a new interface isn’t worth any time investment.
Git is the opposite end of the spectrum for its users. It’s very powerful, manages a complex system, and is many times daily (or even hourly, depending on your style). This means that, while you might have to spend some time in nature reflecting on the Git Koans before you become a master, the up front time investment into learning how to use your tool properly is worth the time investment.
Is the UI unintuitive to the point of being impossible to reason out by oneself? Probably yes. So why isn’t there a widespread wrapper for git to make it more accessible and unified? While the learning curve is steep, the time spent learning Git is infinitesimal in comparison to the time you’re going to be spending using it, and the time it saves you with its power.
See my rejoinder about Bazaar above.
My argument is that the bad UI doesn’t matter at all. It’s a trivial thing to get over in order to be able to use the most widely used version control system. For the sake of argument, let’s say to learn the basics of how to use a vcs for everyday use takes 5 hours of dedicated learning and maybe another 15 hours to know all the ins-and-outs. The vast majority of that time, whether using Git or Bazaar or Mercurial, is going to be learning the complexities of the system, not the quirks of the UI.
Getting over bad UI is not trivial. There’s a lot of research to back that up.
adsouza is right given decades of research show how bad UI holds people back. There’s another angle to this, though: wasted effort. This tool was created by a guy for his project’s needs that didn’t care about UI. He’s highly technical person fond of delving into the details of his work with command lines & such. Ludicrous that everyone of all types of thinking or personal preferences needing a DVCS should be forced to expend lots of effort trying to work around that. Instead, the app and its model should’ve had good UX built into it.
Instead, they just don’t care. It’s apathy, not complexity, that’s the reason using Git is so difficult for newcomers. Worth remembering in these discussions.
This tool was created by a guy for his project’s needs that didn’t care about UI.
This also describes stack, which cares so little about UI needs it duplicated the name of a foundational computer science concept and the most popular programming site in the world.
And, (not) coincidentally, that did result in me being confused by the first titles I saw about it that looked like nonsense. Good prediction, there.
I am impressed that by 2012, it was already the consensus that Git was a pioneer in distributed source code management when, in actual reality, it was a replacement for BitKeeper, which had been used by kernel developers for years and was the innovative product that everyone else copied. But without that narrative, you’d have to come up with a better reason for the chaotic git command set and its fragility.
You’d be surprised how many times I’ve heard from Git users how VCS went from centralized in Subversion to decentralized with the wonderous invention of Git. That’s despite the official history of Git saying exactly what you said about BitKeeper & Git. Far as bad UI, Linus et al don’t need any narrative to cover for that. It was standard practice in Linux forever until some commercial Linux’s showed it could be better followed by groups like Canonical.
Other than technical or philosophical issues, the main change of the git/github revolution has been this:
Burden of VCS maintainance pushed to contributors
I no longer contribute to a lot of projects, but I still remember when sending a patch was as easy as download the zip sources (or cvs checkout), copy the files in a new directory, edit and run diff. Send the diff file to the maintainer.
Now things are more hairy and I fail to see the benefit. Don’t get me wrong, github has greatly extended visibility of software projects, and added a ticketing system, but they did it in spite of git.
I agree with you about the github pull request model (that bitbucket, gitlab, etc have copied), but that is not git’s fault. Applying a diff is easy in git [git apply <foo.diff>]. Git provides an way to prepare a mail with the patch (git format-patch) and sending it (git send mail) to make the contributors life easier.
git apply <foo.diff>
Too bad this approach is not more common for FLOSS projects this days, not only is the gh pull-request model more complex but in practice it locks valuable information about the project’s history on github as most people this days explain the changes in the pull request comment, not in the commit message.
[Comment removed by author]
Rebase permanently destroys information, right?
Well, not really – it creates new commits that are altered versions of existing ones, but doesn’t delete the originals. (If the originals remain unreferenced by a tag or branch for long enough they’ll eventually get GCed, but if you do want to retain all the original information unmodified it’s easy enough to do so.)
It’s only easy if you already know the hashes of the original commits. Git does not surface this information to you easily.
See man git reflog or http://stackoverflow.com/questions/134882/undoing-a-git-rebase
man git reflog
As @1amzave said, the commits are around, see git reflog.
As for being lies, they cease being lies when merged to master. The ability to craft a clear log (better word than history) of commits before merging is a superpower.
It also helps promote committing often, because it doesn’t matter if you have a “whoops forgot to initialize foo” commit in your feature branch, you can clean that up before merging to master.
Unfortunately this needs to be enforced at the code review level, which pull request workflows actively work against. Very often pull requests contain commits leaving the repo in an unbuildable state. I tend to think of VCS as an attempt to tell a story about how something was built rather than a reflection of what actually happened. Unfortunately this takes a lot of effort to pull off well…
Unfortunately, no amount of complaining about the complexity of tools designed to tackle complex problems saves us from having to learn to live with complexity. Life is complex, that’s why we’ve evolved to grow so many neurons inside our skulls.
If I understand you correctly: git is as complex as distributed version control, no more?
There’s obviously some incidental complexity, but I’d say it’s negligible compared to the inherent complexity of the underlying “commits are snapshots, branches are pointers” model. Put another way, I personally find such cosmetic complaints, as well as the attempts to fix the cosmetic inconveniences in git to be unproductive. I think there’s much more to be gained by trying to explore fundamentally different views of the VCS problem. One example is darcs and its “patch theory” foundation.
I find Bazaar much easier to use than git and it deals with exactly the same problem domain and even handles directory renames better than git while not being worse in any way other than performance, which should have no bearing on the complexity of the UI.
Could we not just produce something git-like that drops the whole “index” concept? This seems like an extra git-only layer that adds a lot of complexity, interacts poorly with other commands, and is not at all fundamental to the DVCS model - indeed it seems to have no solid theoretical underpinning at all.
Anyone know of a decent GitLab / Gogs type application that does both Git and Hg? I found HgLab and RhodeCode but both seem to be limited to specific OS (windows and nix respectively).
Kallithea is a community fork of rhodecode.
Gitlab is Linux only. HgLab is Mercurial only.
RhodeCode had a dedicated windows version until 3.8.X version that still exists. Currently, there’s only OVA/Docker for windows.
RhodeCode also has the Free Open Source Community edition similar to Gitlab
Wow this is the worst movie I’ve seen all year, and I saw independence day 2.