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
In my experience doing mentorship, a lot of people are taught git in a super rushed way and tend to have the mindset of "here's this incredibly complicated program you will never understand, please learn these magic commands and hope you never get a merge conflict" which isn't particularly useful because they're now scared of their tools.
We need to teach tools like git (and some editors!) as their own thing, completely separate to programming languages. Not "now we've written some code, let's put it in git" but "here's a tool called git, let's show how it works with some text files"
Honestly - you spend 20 minutes with someone teaching them that git only stores diffs and how that actually works and they leave much more confident and willing to experiment on their own.
A plain text TODO list is absolutely perfect for this, because a merge conflict between two steps on a numbered list is completely intuitive and resolvable. "I've got two 4)s now!" "What's the fix?" "I guess one needs to become 5)?"
(The CLI and naming scheme is total garbage though - biggest hurdle for non-native English speakers IMO)
We need to teach tools like git (and some editors!) as their own thing, completely separate to programming languages. Not "now we've written some code, let's put it in git" but "here's a tool called git, let's show how it works with some text files"
Honestly - you spend 20 minutes with someone teaching them that git only stores diffs and how that actually works and they leave much more confident and willing to experiment on their own.
A plain text TODO list is absolutely perfect for this, because a merge conflict between two steps on a numbered list is completely intuitive and resolvable. "I've got two 4)s now!" "What's the fix?" "I guess one needs to become 5)?"
(The CLI and naming scheme is total garbage though - biggest hurdle for non-native English speakers IMO)
Honestly - you spend 20 minutes with someone teaching them that git only stores diffs
...except that isn't what git stores (as loose objects); in fact it's one thing that distinguishes git from earlier tools. See eg https://medium.com/@paritosh90/understanding-git-internals-c...
...except that isn't what git stores (as loose objects); in fact it's one thing that distinguishes git from earlier tools. See eg https://medium.com/@paritosh90/understanding-git-internals-c...
Yeah, I had this misconception for a while.
I think it's useful to understand how git actually stores objects as blobs and trees, but the mental model of "commits are diffs" is still useful. Commands like git-cherry-pick really make the most sense when thought of in terms of diffs. Internally, for a command like that, git is taking the diff and applying it, anyway, so the model isn't really that inaccurate.
I think the main place I've seen where the mental model of "commits are diffs" breaks down and actually leads to significant confusion and/or mistakes, is when the tree ends up in a weird state, such as in the middle of resolving a merge conflict.
In that situation, it's important to keep in mind there's three separate tree-like things: the actual working tree; the index; and HEAD. And git status shows nothing more or less than the diff between the working tree and the index. I've gotten myself out of some confusing situations just by reminding myself of that and thinking things through very carefully.
I think it's useful to understand how git actually stores objects as blobs and trees, but the mental model of "commits are diffs" is still useful. Commands like git-cherry-pick really make the most sense when thought of in terms of diffs. Internally, for a command like that, git is taking the diff and applying it, anyway, so the model isn't really that inaccurate.
I think the main place I've seen where the mental model of "commits are diffs" breaks down and actually leads to significant confusion and/or mistakes, is when the tree ends up in a weird state, such as in the middle of resolving a merge conflict.
In that situation, it's important to keep in mind there's three separate tree-like things: the actual working tree; the index; and HEAD. And git status shows nothing more or less than the diff between the working tree and the index. I've gotten myself out of some confusing situations just by reminding myself of that and thinking things through very carefully.
> I think the main place I've seen where the mental model of "commits are diffs" breaks down and actually leads to significant confusion and/or mistakes, is when the tree ends up in a weird state, such as in the middle of resolving a merge conflict.
Not really?
With git you just keep track of three things:
1. The actual committed code 2. Code that's in the staging area 3. Code on disk right now
(git has official names for these but I forget)
Then during a rebase, if there a conflict, the base comes from the parent of the commit (in 1) you are applying the new commit on top of and the conflict is basically how the new commit makes changes w.r.t to the latest commit in 1. This conflict is written to 3 for files that are in conflict (and to 2 for files that aren't) and then you can resolve the conflict in 3, move the new code to 2 and commit that to 1. You can think of all of it in terms of diffs.
Not really?
With git you just keep track of three things:
1. The actual committed code 2. Code that's in the staging area 3. Code on disk right now
(git has official names for these but I forget)
Then during a rebase, if there a conflict, the base comes from the parent of the commit (in 1) you are applying the new commit on top of and the conflict is basically how the new commit makes changes w.r.t to the latest commit in 1. This conflict is written to 3 for files that are in conflict (and to 2 for files that aren't) and then you can resolve the conflict in 3, move the new code to 2 and commit that to 1. You can think of all of it in terms of diffs.
> Commands like git-cherry-pick really make the most sense when thought of in terms of diffs.
Also "git show <commit>" will show you some metadata + diff, which doesn't really help either.
Then again I'm just happy remembering that parent commit + diff is effectively equivalent to a specific tree. So as long as your think of a patch attached to a specific parent commit you're not really wrong.
Also "git show <commit>" will show you some metadata + diff, which doesn't really help either.
Then again I'm just happy remembering that parent commit + diff is effectively equivalent to a specific tree. So as long as your think of a patch attached to a specific parent commit you're not really wrong.
There's tons of resources about Git out there and a good percentage of them seem to be written by people who don't understand their audience or simply like churning out elitist content nobody wants to read.
I personally found 'How git works' by Paolo Perrotta on Pluralsight to be one of the best out there.
> (The CLI and naming scheme is total garbage though - biggest hurdle for non-native English speakers IMO)
I also don’t like the `command <subcommand>` syntax but I’m not sure any naming approach can make life easier/harder for people unfamiliar with the language.
You do réalise that the author of git is not a native speaker of English?
I also don’t like the `command <subcommand>` syntax but I’m not sure any naming approach can make life easier/harder for people unfamiliar with the language.
You do réalise that the author of git is not a native speaker of English?
I do think git isn't user friendly. I came from perforce and also had a hard time building the mental model. Eventually I read the article about git's internals, and finally got the idea. What's most useful for me was the diagram of the three states (https://stackoverflow.com/questions/3689838/whats-the-differ...).
some 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.
some 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.
> some of the git's naming was also not intuitive for me
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.
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 it is also true that many of us use github or similar with a PR workflow rather than the way Torvalds and the Linux core maintainers use git.
I don't think I know any other workflow but the PR based one.
> some of the git's naming was also not intuitive for me, For example, calling the scratch area "index".
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.
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.
Weird naming is definitely part of the problem. I think the other part that makes git painful for beginners is that it does not mandate a workflow (do you have a central authoritative server? where is it? Do you merge master into working branches? Rebase all the time or never at all? Squash commits, or not? Etc). That means that as a newcomer you have to decide for yourself what workflow to use (at a point in time when you have no experience to help you in making that choice) and when you read tutorials or advice online you have to be able to spot whether the author of the advice is using the same workflow you are or whether their suggestions and command line options will not work in your situation. Earlier version control systems tended to be more dogmatic about how they were used, which is less flexible but easier to get to grips with.
I think the other part that makes git painful for beginners is that it does not mandate a workflow
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 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 it does not mandate a workflow
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.
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.
> 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. > 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.
> * 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.
> By your definition, if we delete a commit, the subsequent commits should remain unchanged
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).
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).
> if we delete a commit, the subsequent commits should remain unchanged
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!)
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!)
> 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.
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.
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.
People might be interested in gitless [0], which purports to be "a Git-compatible version control system, that is easy to learn and use". It appears to be built on top of git, using a simplified conceptual model.
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...
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...
Having used SVN for a decade before we all moved to git, I have to say I've never noticed any improvement in our productivity. I.e. the limiting factor wasn't how well you can do a merge.
In fact I've probably experienced more cock ups with git due to its increased complexity and insane naming scheme. I mean "checkout"... Completely inappropriate for what it does.
Obviously with git you can work offline then sync later on, but that's not something you have to deal with in most organisations.
In fact I've probably experienced more cock ups with git due to its increased complexity and insane naming scheme. I mean "checkout"... Completely inappropriate for what it does.
Obviously with git you can work offline then sync later on, but that's not something you have to deal with in most organisations.
Hmmm, during your decade with subversion, did you ever try working with branches?
Of course - but we were still productive using SVN. The improvements in git didn't really give us a massive boost in productivity.
The different flavors of processes using git are where I see significant differences in how hard it is to use. GitHub/GHE encourages pull requests and force-pushing a candidate branch. Gerrit encourages a staged-commit via "refs/for/$dest_branch". Projects like QEMU and the Linux kernel are much more decentralized and leverage requests to pull from dev repos and email patches ('git send-email'). All of these differences have some impact on how you use git locally and how easy or difficult it is to recover when you make a misstep.
Subjectively I think that - the staging area is unnecessarily confusing (mercurial did this better imo), and the overloading of 'checkout' causes confusion too.
Subjectively I think that - the staging area is unnecessarily confusing (mercurial did this better imo), and the overloading of 'checkout' causes confusion too.
My pain points with git are the detached head states (so puzzling) and basically everything that concern submodules (very brittle.)
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.
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.
No. I had to use mercurial at my old job and everyone in the company saw mercurial as an easy and efficient alternative to git - something which I could not comprehend. And truthfully after using the "easier" solution, I'd rather take the code, print it out on punch cards and compare them in order to create the adequate changes by taping the holes accordingly and feed the punch cards back into the computer. Now that I'm saying it and having looked at how mercurial works underneath, it's not far off, with the exception that mercurial creates copies of all punch cards and keeps stacking them on top of each other. I've never hated any version control as much and I've had to use svn in the past. Git operates on a strict and crazy stupid model without adding unnecessary features and advertising them as "flexibility" or "ergonomics". I've worked with juniors who've never used git in the past and in all instances it took them a day at most to figure out how it works.
We use mercurial at work. I actually like it very much (of course it might be because we follow a certain workflow).
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.
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.
That's the point: you have to follow a workflow to make it even remotely usable. And even so, they are hacky workarounds at best and generally mercurial feel like the product of "that's good enough". And in a more general sense mercurial feels like(and in fact historically is) the product of unsolicited help. The concepts of having separate actions for pull and update are ridiculous. The --new-branch option is equally stupid. Many basic features are missing and you have to resort to stuff such as plugins like evolve or whatever it was called(say rename an existing branch without causing the universe to implode on itself). Back-merging in mercurial makes no sense if you live with the basic assumption that you have one default/master/main or whatever you wanna call it branch. And truthfully, storing the entire history of your work as diffs is what I'd assume Gutenberg would have come up with - great for the 15-th century but sticks and stones by 21-st century standards. And a ton of other basic features are either missing or a complete hack - stashing, rebasing, update-index, submodules and all the things which personally as a git user, I take for granted.
SVN isn't that bad at all.
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.
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.
I mean... Credit where it's due: it certainly beats mercurial for me.
Git it fine, maybe the naming could be better, but it's just something that anyone can get used to. The real issue is crazy workflows people tend to invent instead of using something common like Gitflow.
But I have to admit that I prefer Mercurial, enforced immutable history makes everything easier. Also, I root for new alternatives like Pijul.
this always makes me laugh:
https://youtu.be/3mOVK0oSH2M
edit: start at 3:00 mins in
edit: start at 3:00 mins in
First 40 minutes are pure gold. He kept a straight face all through it, and made sure to not overdo it. An unsuspecting Git student would have no clue.
Makes it very difficult to trust anything he says or does in the following segment.
Makes it very difficult to trust anything he says or does in the following segment.
This is the only git manpage you’ll ever need:
https://git-man-page-generator.lokaltog.net/
https://git-man-page-generator.lokaltog.net/
When he entered the command and it started scrolling I was like "oh, I didn't know git had so many commands".
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.
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.
395K commands only needed for daily use, lol
[deleted]
Respectfully, version control is not necessarily easy, and even with other versioning tools (they already exist, and some purport to be easier than git), you still have to think about what you're trying to do. I see this attitude a lot with new developers, and it's troubling. Of course git is hard; what part of computing _isn't_ hard? Git is a hell of a lot easier than, say, debugging a kernel panic, or solving a tricky race condition. If the vast majority of developers can't get by without learning anything beyond clone-commit-push, then I truly fear for our industry, because I am thoroughly average, and I have a pretty good idea of what git is up to when I run commands.
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.
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.
Personally, having used it for over a decade now, once you learn how it works, git is perfect. But it's not necessarily easy, sure. But then there are a lot of easy solutions out there that aren't very good. I'd say it's worth the investment to learn it, but I've seen so, so many developers refuse on the grounds that they simply don't want to. These are the folks who think it isn't good, the ones without experience.
The system has actual complexity. Actual complexity can't be abstracted away without reducing functionality. I think git has a poor/opaque command semantics outside the basic functions and the API could use some work. I think that a new review or "most used/useful commands" and an evaluation of whether the API to accomplish them can be simplified.
There are other projects attempting to tackle that complexity; namely https://pijul.org/
Gitless [1] has already been mentioned in another comment here. [2] That makes it easier to use git for those who are not as experienced or haven’t learned about the internals of git.
For a different model (and other types of workflows), consider Fossil SCM. [3] Here’s a comparison of fossil with git, and what these tools are a good fit for. [4] I found fossil easier to understand, relatively speaking, and it seems simpler for personal use and for small teams.
[1]: https://gitless.com/
[2]: https://news.ycombinator.com/item?id=29757043
[3]: https://fossil-scm.org/
[4]: https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v...
For a different model (and other types of workflows), consider Fossil SCM. [3] Here’s a comparison of fossil with git, and what these tools are a good fit for. [4] I found fossil easier to understand, relatively speaking, and it seems simpler for personal use and for small teams.
[1]: https://gitless.com/
[2]: https://news.ycombinator.com/item?id=29757043
[3]: https://fossil-scm.org/
[4]: https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v...
There are definitely warts and sharp corners. Inconsistent cli api. The story for binaries with Git-LFS is still a mess (try using git over SSH with LFS or explain to a newcomer why it doesn’t work). Conflict resolution is still half stupid with very few easy ways of adding better more specialized merge drivers and deploying it over a company. Improvements like ReReRe and similar aren’t well integrated and enabled by default. Instead they are obscure additions so that you can get a less infuriating behavior. But only if you press the right buttons first.
The worst aspect of it though is you can’t set it up to be properly centralized so that you truly bless a location which can keep things like branch name policies, distribute hooks to all employees etc. All that has to be built (poorly) on top, with ample opportunity to accidentally sidestep.
The worst aspect of it though is you can’t set it up to be properly centralized so that you truly bless a location which can keep things like branch name policies, distribute hooks to all employees etc. All that has to be built (poorly) on top, with ample opportunity to accidentally sidestep.
Technically, LFS isn't part of git and was added by a third party to solve a problem they had.
Yes. And it shows up as a massive hole in the feature set of git. Had it been a first class citizen together with other centralized workflow features, then obviously lfs would have worked over ssh.
git is that it’s a tool written to solve distributed version control for Linux which is nearly the only project that’s effectively using distributed version control.
Everyone else uses git for centralized version control. And it’a not a perfect fit.
git is that it’s a tool written to solve distributed version control for Linux which is nearly the only project that’s effectively using distributed version control.
Everyone else uses git for centralized version control. And it’a not a perfect fit.
Overall IMO, Git is so good that if you have a problem with usability, it's better to work on a wrapper around Git than it is to change Git itself.
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.
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.
The CLI could be simpler without making it less powerful. For example, "the index" should not be visible to the user, IMO. The usecases it enables can be achieved with a simpler CLI (like Mercurial does).
Also, stashing could be automatic and rebase could also rebase descendant branches.
Also, stashing could be automatic and rebase could also rebase descendant branches.
> and rebase could also rebase descendant branches.
Why??
This sounds like something that could break tons of workflows
Why??
This sounds like something that could break tons of workflows
See https://stackoverflow.com/questions/5600659/rebasing-a-branc... and its many duplicates. I think that's what users typically want.
I fully agree. The challenge here might be if it's not a single user repo, how does the simple frontend deal with tricky cases introduced by other users?
It probably wouldn't deal with it "well enough". Although, any errors or validation failures would point the user to use git commands to restore peace and order before using the tool again.
No, we need the power that git offers us for scaling workflows and contributions to large ecosystems. Software does not get less complex over time, but more complex - and we need a system to handle contributions to a complex system (read: large, distributed, multi-thousand developer/files codebase)!
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!
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!
git is as simple as possible while being as powerful as possible
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').
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').
I think that mercurial (but also bzr) had a more understandable CLI and ux than git.
Unfortunately git won the DCVS war.
Yes, it's called Mercurial.
So the answer would be, no it's Mercurial.
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.
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.
> 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.
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.
I don’t feel so. Beginners can learn a handful of commands to gets started. And once they started to contribute to a production project they anyway have to learn some additional advanced commands (mostly rebase on top of others changes and conflict resolution). Things beyond a rebase a rarely used by anyone, so most people can just avoid learning those or learn when necessary.
Working with git for 5 years and SVN for 15 before that on teams ranging from 2 to 30 people, I think the problem of collaborative programming just isn't solved yet.
It's not that git is special or especially hard. It's that distributed source control is a hard thing to understand, and no 20 minutes tutorial is going to solve that.
It's not that git is special or especially hard. It's that distributed source control is a hard thing to understand, and no 20 minutes tutorial is going to solve that.
I’ve used Git Tower for years because I dislike commandline.
Git tower is a “simpler git” that makes many complex tasks safer and easier. But it’s on top of git so you have the full power of git if you do have to jump into the commandline.
https://www.git-tower.com/mac
Git tower is a “simpler git” that makes many complex tasks safer and easier. But it’s on top of git so you have the full power of git if you do have to jump into the commandline.
https://www.git-tower.com/mac
Maybe just an optional second cli for git that improves usability? If it takes off, switch it to default. Are there any examples of a cli tool with multiple, user selectable cli interfaces?
Edit: to answer your question, there’s a lot of value to learning the standard industry scm tool.
Edit: to answer your question, there’s a lot of value to learning the standard industry scm tool.
Yes there is. But there would be a tremendeous value to make the standard industry scm tool as user-friendly as possible. There are few tools where you would want to prevent user-errors more.
There are tools out there that attempt to provide a simpler and/or more powerful CLI while letting you collaborate with others on existing Git repos. Gitless has already been mentioned here, but there's also my own tool (https://github.com/martinvonz/jj) and git-branchless (https://github.com/arxanas/git-branchless).
[deleted]
Much of the complex parts of git have to do with rebasing and merging.
But I remember that Pre-git this was hard too - the lack of features in VCS systems made it rather error prone. I recall manual 3-way merges and long conversations with colleagues about the right way to work through an SVN merge. Not to mention automated testing was less widespread, so it was harder to catch bugs.
Git offers more features here. But the truth is the problem is just hard. Combining changes from multiple authors requires knowing both your tooling and code well.
But I remember that Pre-git this was hard too - the lack of features in VCS systems made it rather error prone. I recall manual 3-way merges and long conversations with colleagues about the right way to work through an SVN merge. Not to mention automated testing was less widespread, so it was harder to catch bugs.
Git offers more features here. But the truth is the problem is just hard. Combining changes from multiple authors requires knowing both your tooling and code well.
No matter how many times I do it, i have troubke squashing.
Maybe I am just dumb .
Maybe I am just dumb .
git reset <parent> —soft; git commit -m squash
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.
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.
Yeah. Git is great software, but there's seriously no reason I should be typing multiple CLI commands over and over again as part of my workflow in the year 2022.
Ok, so I don't know your exact workflow as it could be some weird branch hopping and squashing and reflog breaking weirdness, but:
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.
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.
Use a GUI client. There are many of them.
Then set up an alias to do it for you.
https://alblue.bandlem.com/2011/04/git-tip-of-week-aliases.h...
https://alblue.bandlem.com/2011/04/git-tip-of-week-aliases.h...
bash has a history search feature you can access via control-r.
No, but something like magit should be provided out of the box with git. Git is pretty simple, but having a good user interface is essential.
I work with hundreds of developers with git, and yes 80% of them only know the basic workflow. The other 20% know a good bit more and can resolve any problem that occasionally comes up. I don't think it has hindered our development at all. People understand how the tool works for what they need, at the level they need. I'm good with that.
Basic git flow operations are straightforward. I taught a few graduates who had no prior vcs experience and they had no problem with day to day stuff. Because git is truly a powerful tool its ux becomes complicated once you need to do something beyond the simple operations.
Have you used any other DVCS other than git? Bitkeeper ux us vastly better. Git ux is rough.
It might be useful to be able to write git commands in more descriptive way for beginners. “Git add all new files”, “Git commit all files with message ‘foo’”, “Git show history of file ‘readme.txt’”, “Git restore previous version of file ‘readme.txt’”, etc.
No.
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
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
Mercurial was kinda that, and we mostly moved every mercurial repo to git.
I used the GIT GUI, and it seems easy enough for me, though I haven't pulled things out of repositories yet, just stage/commit | push to github
What's needed is better documentation, nothing more.
What's needed is better documentation, nothing more.
> Git is amazing
Let me take a wild guess here, bud, you are definitely an american, amiright?
Git is shit, it just happens to be better than the competition coupled with the fact of its huge market share.
Let me take a wild guess here, bud, you are definitely an american, amiright?
Git is shit, it just happens to be better than the competition coupled with the fact of its huge market share.
Since you should not be working in ways that create merge conflicts if you can avoid it I would say a simple distributed disk backup would be enough for 99% of programmers.
Git is complex, which is fine.
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.
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.
git is worse than Linux in terms of UI
Yes
No.