Ask HN: Do we need an easier Git?
Git is amazing and essential for my work. However, a vast majority of developers just use the clone-commit-push workflow and can get by. I've also taught CS to younger kids and seen students struggle to internalize the mental model of Git. The learning curve is steep for early devs. Is there merit in having a VCS that has a less steep learning curve or are the benefits of knowing a universal VCS too great (even if you end up using a small subset of the features)
95 comments
[ 2.3 ms ] story [ 83.4 ms ] threadsome of the git's naming was also not intuitive for me, For example, calling the scratch area "index". I didn't seem to have to learn perforce, cvs or svn's internals to use them fluently.
but I guess it's a bit difficult to change the current situation. git has become the most common choice. And once the mental model has built, it's not that difficult to use, admittedly I only use a few very common commands.
you know the challenge won't be building the version control. for mass adoption, you need a github-like platform.
For me this was (and is) the main source of "what is this and how do I use it" problems. Git is supposed to be an advanced tool to make snapshots of a folder, save them in a tree structure with multiple leaves, combine or even modify them, keep a copy remotely, etc.
So, you are probably expecting to find a "save" command, an "upload/download", maybe a "combine snapshots", and for more advance tools an "edit history". But instead you have "commit", "push/pull", "merge" and "rebase". Those are less intuitive (specially for non English speakers) so you end using only the few ones someone told you to use.
Once I realized what "fixup" was and how to use it I can't stop using it.
Git model is no so complex, the naming is, so it's like learning a whole new language and it takes time.
I think this is the real problem. Git is actually really simple. The mental model is not even difficult - you can describe it in a sentence or two.
* Each commit is a snapshot of your code at a certain point. Like making a copy of your project and renaming the folder (but stored more efficiently). Commits also include metadata to say which previous commit(s) they are based on.
That's it.
All the difficulty comes from figuring out what the hell all the badly named and confusing commands do. As you mentioned I think "the index" is probably the worst - why not "draft commit" or just "draft"? That's what it actually is. It's so bad people even invented an unofficial name for it ("staging area").
It's not the only one. "Commit" is a pretty bad name in itself. It's not even a noun - "snapshot" would have been better.
And there's the commands... Look up how many different things `git checkout` does, or `git rev-parse`. And don't ask me how many times I've googled "git delete remote branch".
They did add `git switch` so I'm mildly hopeful that at least some people care.
That's a very good point. Every company I worked at that used SVN back in the day used it in basically the same way, making it very easy to get started. With git different projects even within the same company can have completely different workflows.
that's the only reason it gain adoption among other projects, which already had (different!) well-established workflows and let to it being where it is now.
> * Each commit is a snapshot of your code at a certain point. > That's it.
Unfortunately, it's a bit more nuanced than that. What you described is only git's storage format. Git operations and UI unfortunately isn't consistent with that model. Take for example, interactive rebasing. By your definition, if we delete a commit, the subsequent commits should remain unchanged - because commits are only snapshots after all. But that isn't what happens. The change introduced by that commit gets deleted from all subsequent commit. Commits are treated as diffs here.
Git UI switches between snapshot and diff model quite often. Merges and rebases are all patch operations. Novice users can get away with being oblivious to this change for most operations till merges. But rebases require you to be aware of it. Even for experienced git users, large multi-commit interactive rebases are hard because git simply hides all the nuances of patching (you are better off rebasing in small chunks). This becomes immediately clear when you use a tool like quilt or stgit. In my opinion, this is something that prevents beginners from going beyond clone-commit-merge workflow and being able to create beautiful commit history like that of the kernel.
And that's exactly what happens. On a rebase, the original commits are not deleted, but the command creates new ones that matches the same diffs (unless there is a problem like an empty commit or a conflict).
Normally those unused commits are 'lost' because no branch/pointer are now pointing to it, unless you have another branch which does. Later the gc removes those orphaned commits (although I think you do can restore them before that happens).
They are. You can get to them using the reflog.
> Commits are treated as diffs here.
Not exactly. For the rebase operation Git calculates the diff between subsequent commits and then reapplies them to make new commits, but the commits themselves are never treated as diffs.
> Git UI switches between snapshot and diff model quite often.
It doesn't. It allows you to perform operations that result in or consume diffs, but of course it does! They're useful things to do. How else would it work? It never treats commits themselves as diffs because that doesn't make any sense. Only the differences between two commits are treated as diffs (hence the name!)
Being simple and being easy to use are two different things. Brainfuck is simple, but writing a hello world is hard. Python is superficially easy at the beginning, but I wouldn't call it simple. There is a balance to find between simple and easy, and git is on the simple side, at the cost of the easy.
Edit: to answer your question, there’s a lot of value to learning the standard industry scm tool.
What's needed is better documentation, nothing more.
edit: start at 3:00 mins in
Then it kept going, and going, and I started to feel fear.
I think I'm going to use this when someone tells me "git is easy"
Edit: I think the video was a joke, I don't find that list anywhere. Very funny anyways.
https://git-man-page-generator.lokaltog.net/
Makes it very difficult to trust anything he says or does in the following segment.
Maybe I am just dumb .
The first command sets your current comment to parent, with any changes staged, the second commits it.
I don’t mess with the interactive rebase. There’s a magic combination of this and the reflog that can preserve commit history, too.
Git might not have the best interface, and you could argue for different models, but some of this stuff just takes time and effort to learn. This is an important lesson for new developers to learn: some of this stuff is not, in fact, easy, and I don't where this expectation that it is comes from. It reflects a disturbing trend of learned helplessness I've noticed from newer developers. Computers are hard, but if you want to be the expert, you're going to have to figure it out. I don't think we need easier version control, I think we need developers who are willing to learn hard things.
I don't claim the git CLI is always logical. But you seem to complain that there is one.
1. Most terminals have command history, so if you're really typing the same thing over & over & over & over... just use that? 2. Even if that's not the case, bash/batch/powershell scripts to automate things? 3. Most IDEs nowadays have pretty solid git integration so if you're wanting to click things, there's that.
https://alblue.bandlem.com/2011/04/git-tip-of-week-aliases.h...
Maybe a plain English tool that just lets you click through menus to dictate what you want to do. No Git lingo whatsoever. Very rough examples below:
1) "I want to save my progress". (combination of git add and git commit) 2) "I want to go back before my previous save." (`git revert` on your last commit) 3) "I want to upload my latest work." (git push) 4) "I want to pull in any new updates." (git pull)
...Et cetera. Stuff that's basic enough to satisfy some basic use cases.
Then, for anything more complicated than this basic subset, users have to whip out the terminal. The balance between basic and complicated, and too little vs too much, might take time to figure out.
Also, stashing could be automatic and rebase could also rebase descendant branches.
Why??
This sounds like something that could break tons of workflows
I also used to like when I did not understand git well. After years of learning I mostly understand git and have mostly forgotten that Mercurial exists.
Meanwhile after years of learning I mostly understand git (and am pretty much the reference for colleagues) and I still wish more or less daily its UI wasn't so absolutely shit.
Also revsets, good god of all the awful things in git's UI gitrevisions(7) ranks so, so high.
People take that to mean they need to learn and teach git in intricate detail, and use it in ways that are needlessly complex, which is dumb.
Subjectively I think that - the staging area is unnecessarily confusing (mercurial did this better imo), and the overloading of 'checkout' causes confusion too.
Perforce on the other hand when it is set up for pessimistic locking, that was interesting when I had to use it in a team setting and trying to work from home 14 years ago.
When I try to use git for personal projects (because everyone uses it and I'd like to learn it) and I really am struggling sometimes to get even the simplest workflow working as a single person. I can't even imagine how it would work when having multiple people work together.
I read about it in one of Adrian Colyer's "the morning paper" blog posts from 2016, "What’s wrong with Git? A conceptual design analysis" [1], which summarizes the paper that critiques git and describes gitless. (The link to the paper at the beginning of the post no longer works, but a commenter suggested this [2] instead.)
I should point out that I've never used gitless, and I don't know whether it's still maintained, but if nothing else the critique itself is interesting.
[0] https://gitless.com/
[1] https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-c...
[2] https://web.archive.org/web/20131230194321/http://people.csa...
Anything about undoing commits, going back to a specific version of the code is less painful but I almost always have to google for it because that are not daily operations and I can't reliably remember them. Maybe that would be easier if I used a GUI instead of the command line. Anyway, a simplified git with only basic functionality and dead simple error messages AND part of the standard git distribution would be very useful. After all git does a lot of things but I'm using only a core 1% of it. Even after 10+ years I reliably know only the basic clone, add, pull, push, checkout, branch, commit, merge, rebase, log, diff commands. I have to google everything else, even how to track a remote branch. It's checkout -b but Gould I also fetch and pull it before? You got the idea.
And it should be about files, directories and branches, the stuff developers reason about.
It was initially hard.
But once I read through the excellent Git Book[1] things became very clear and intuitive.
[1] https://git-scm.com/book/en/v2
git is as simple as possible while being as powerful as possible.
What we need is better education! Not only how git works, but also how clean and scaling development workflows work. I've seen too much "Lets just copy the code to the production environment"-workflows in my live already and I do not even have 3 full years of professional experience as a SW dev!
This is far from being a foregone conclusion and would need a careful analysis to justify. FWIW Fossil manages to make do without Git's (insanely named) 'index' (what everyone calls the 'staging area').