7 ms·

The issue with git is that no matter how well documented, the user interface is horribly designed. For starters, how many different things does "git checkout"

The issue with git is that no matter how well documented, the user interface is horribly designed. For starters, how many different things does "git checkout" do, and how many of them actually reflect an intuitive meaning of "checking out" ?

sirsuki 6y ago
Is it true to think that because they made some choices early on that those choices forever blemish its value even is said choices are later addressed? Much of the complaints about checkout have been split to other commands in newer versions. Does this make Git still invalid in your opinion?
tomxor 6y ago
> the user interface is horribly designed I see this type of remark against git quite often on HN and I think it's exaggerated. I agree some of the porcelain are misleading and overloaded as convenience functions such as checkout, however a decent chunk of it is inline with the underlying data structure. Nothing is perfect, and git is pretty damn good - horribly designed? no, could do with some breaking porcelain re-writes? sure.
- masklinn 6y ago
  The git UI is absolutely horribly designed, as demonstrated by the mercurial or darcs UIs which, while completely different, were significantly easier to discover, intuit and remember. > git is pretty damn good UI-wise, it really is not.
  - kazinator 6y ago
    The concept of the git staging area is utterly superfluous. All local changes that are propagated to the version control system should go directly into a durable commit object, and not to a pseudo-commit object that isn't a commit, and that can be casually trashed. That commit object could be pointed at by a separate COMMIT_HEAD pointer. If you have a COMMIT_HEAD different from HEAD, then you have a commit brewing. Finalizing the commit means moving HEAD to be the same as COMMIT_HEAD. (At that time, there is a prompt for the log message, if one hasn't been already prepared.) Your "staged" changes are then "git diff HEAD..COMMIT_HEAD", and not "git diff --cached". Speaking of which, why the hell is "cached" a synonym for "in the index"? Oh, because the index holds a full snapshot of everything. But that proliferation of terminology just adds to the confusion. I can't think of any other area of computing in which "cache" and "index" are mixed up.
    - saagarjha 6y ago
      I like the staging area, though–at any given time I always have code that I do not want to put in a commit object (perhaps I changed some build flags, or my IDE touched some files I don't care for, or…) However, I do agree 100% that all the terminology is pretty bad.
      - cxr 6y ago
        The sin of Git's staging area is that Git forces it into the default interaction path—requiring you to take it into consideration whether or not you're interested in only committing some of the changes. Git should default to including all changes, and iff you direct it to (i.e. by explicitly specifying `git add`) should you have to take into consideration the notion that some changes are staged and others aren't.
        phorkyas82 6y ago
        I'm generally also one of the git sceptics - Though I loved staging for a while as for the fine grained control. `git add --all` just might not do the right thing - for paranoids like me. Just recently got to know you can skip the staging by appending the paths of the changed files you want to commit after `git commit -m "awesome commit"` - neat.
        kazinator 6y ago
        You can skip the explicit staging using git commit --patch then interactively select the specific changes by diff hunk. It combines with --amend.
      - erik_seaberg 6y ago
        Only the workspace can be built and tested, so the workspace is what should be committed. We should be stashing anything we don't want to test and commit yet.
        kjeetgill 6y ago
  - wk_end 6y ago
    Single data point, but I used hg for three years at work and never warmed up to it the way I've warmed up to git (and that's the "porcelain" too, I've never done a deep dive into the plumbing).
- kazinator 6y ago
  > I see this type of remark against git quite often on HN and I think it's exaggerated. Indeed, in more erudite forums with smarter users, more level-headed, less biased opinions of git circulate.
Joker_vD 6y ago
It's the command that does "Reset working directory/Discard changes/Revert to last commit"! You'd think that's what "git reset" would to, but of course not.
- jlokier 6y ago
  > You'd think that's what "git reset" would to, but of course not. Ahem, the command for "Reset working directory/Discard changes/Revert to last commit" is "git reset --hard". That's the one I use. "git checkout -f" does the same thing, but only because their different functionality coincides when there are no other arguments. When given a non-HEAD commit-id or branch-id they do different things.
  - ArneBab 6y ago
    That’s a beautiful example of the problems of git :-)
dangoljames 6y ago
The one thing that all the negative commentary fails to acknowledge is that even in the face of this somewhat overstated inconsistency across all these command line tools and applications, is that for the knowledgeable and motivated, it is quite simple to wrap the more complex invocations in simplified scripts or, at the other extreme, a completely functional native GUI. They also fail to acknowledge that contemporary unix, aka Linux in it's many derivations and flavors, is entirely malleable at the source code level by it's users. That is a feature provided by literally no other operating system that is deployable at scale, and is, in fact, the singular feature that drives it's adoption -- not only is it 'free', you can hack it together in any fashion you damn well please, and you can use it to build peer-grade native applications, typically with little more than a tip of the hat as 'overhead'. tl;DR: Some folks might miss the point because they are not sufficiently motivated to engage the *nix world with the degree of articulation required to tap into it's less than casually accessible capabilities.
- Joker_vD 6y ago
  Sigh. Why are there still lots, heaps, and tons of horrible, inhumane, broken legacy technology still around in active use? Because its users/proponents are "knowledgeable and motivated" enough to keep pushing through. Sort of a Stockholm syndrome of computing, really. My brain is really quite small compared to all the knowledge about computers that is out there. And my willpower too is very limited. So I would rather learn things I'd rather like to know, and be motivated to do things I'd rather get done instead of spending those precious resources of mine (and time! I will die in less than 25,000 days, that's a pretty small amount of time, you know) on something of dubious value.
  - zdragnar 6y ago
    They are still around because, through historical accident, they are what everyone knows and uses. Making a special snowflake that fits your brain better is good for you, but not necessarily anyone else. Making something good for everyone will, almost inevitably, become a design-by-committee monstrosity that is as problematic as the tool being replaced. The truth is, I am skeptical that these tools can be replaced by something that requires no effort to learn. At least, for the tools we already have, if you dont want to learn them, you can roll the dice and copy / paste from google overflow.
u801e 6y ago
The fundamental assumption is that people will either ask how to do something, or read the documentation/manual. It's not that we'll try to figure out how something work by experimenting. When I first started using UNIX/Linux after learning the DOS shell, I never said that using commands like rm or mkdir were not intuitive and that it should be like using del or md instead. I just learned the different commands by reading through documentation.
- thewebcount 6y ago
  And what if you don't have anyone to ask? The article very clearly states why the documentation is useless for a beginner. Other OSes have a concept called forgiveness that allows you to easily reverse a change you made explicitly so that you can experiment with it and figure things out for yourself. The problem is that Unix fundamentally doesn't allow you to figure things out by yourself. You absolutely need either a manual (that you will never find if you haven't already been told how to find it), or you need to have someone you can ask questions to.
maistho 6y ago
git has added `git restore` and `git switch`, intended to replace `git checkout` :) https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch
WorldMaker 6y ago
In recent versions of git (since 2.23) the two main `git checkout` functions have been split into two newly supported dedicated commands: `git switch` and `git restore`. Of course the next step is unlearning `git checkout` muscle memory and moving to using `git switch` and `git restore` more regularly.
Animats 6y ago
Some time ago, some UI designer asked, on HN, for what open source program should they build a UI to establish their reputation. I suggested "git". That was rejected as too hard. They just wanted to put eye candy on a command, not have to rethink its relationship with the user.
- barbarbar 6y ago
  It was very good idea. Though perhaps establish reputation is probably not a good starting point.
- cxr 6y ago
  A few years back, a designer waded into the middle of the echochamber on some HN thread about inculcating people from other disciplines. They wrote that "as a designer" they did not consider Git (GitHub?) to be thoughtfully put together or well-suited for the kind of work they do or something like that. It was a short comment, about as long as that, and there was no flaw or faux pas or even anything incendiary about it. HN wasn't having it, though, and downvoted it mercilessly. (There were no responses to say why it had been downvoted; the subthread dead-ended there.) It's things like this that remind me of the now-infamous comment in the Dropbox thread. I didn't think at the time to bookmark it with my "hn sucks" tag, and over the past year or two, I've tried several times to find it again, for reasons similar to[1], but I've been unable to. 1. https://news.ycombinator.com/item?id=22991033 https://news.ycombinator.com/item?id=22991033
- cercatrova 6y ago
  Well they were a UI designer and not a UX designer.
mehrdadn 6y ago
I've had a lot of issues with git UI but git checkout seems among the more sane ones. Compared to how, say, git add can remove a file...

sirsuki 6y ago

Is it true to think that because they made some choices early on that those choices forever blemish its value even is said choices are later addressed? Much of the complaints about checkout have been split to other commands in newer versions. Does this make Git still invalid in your opinion?

tomxor 6y ago

> the user interface is horribly designed I see this type of remark against git quite often on HN and I think it's exaggerated. I agree some of the porcelain are misleading and overloaded as convenience functions such as checkout, however a decent chunk of it is inline with the underlying data structure. Nothing is perfect, and git is pretty damn good - horribly designed? no, could do with some breaking porcelain re-writes? sure.

masklinn 6y ago
The git UI is absolutely horribly designed, as demonstrated by the mercurial or darcs UIs which, while completely different, were significantly easier to discover, intuit and remember. > git is pretty damn good UI-wise, it really is not.
- kazinator 6y ago
  The concept of the git staging area is utterly superfluous. All local changes that are propagated to the version control system should go directly into a durable commit object, and not to a pseudo-commit object that isn't a commit, and that can be casually trashed. That commit object could be pointed at by a separate COMMIT_HEAD pointer. If you have a COMMIT_HEAD different from HEAD, then you have a commit brewing. Finalizing the commit means moving HEAD to be the same as COMMIT_HEAD. (At that time, there is a prompt for the log message, if one hasn't been already prepared.) Your "staged" changes are then "git diff HEAD..COMMIT_HEAD", and not "git diff --cached". Speaking of which, why the hell is "cached" a synonym for "in the index"? Oh, because the index holds a full snapshot of everything. But that proliferation of terminology just adds to the confusion. I can't think of any other area of computing in which "cache" and "index" are mixed up.
  - saagarjha 6y ago
    I like the staging area, though–at any given time I always have code that I do not want to put in a commit object (perhaps I changed some build flags, or my IDE touched some files I don't care for, or…) However, I do agree 100% that all the terminology is pretty bad.
    - cxr 6y ago
      The sin of Git's staging area is that Git forces it into the default interaction path—requiring you to take it into consideration whether or not you're interested in only committing some of the changes. Git should default to including all changes, and iff you direct it to (i.e. by explicitly specifying `git add`) should you have to take into consideration the notion that some changes are staged and others aren't.
      - phorkyas82 6y ago
        I'm generally also one of the git sceptics - Though I loved staging for a while as for the fine grained control. `git add --all` just might not do the right thing - for paranoids like me. Just recently got to know you can skip the staging by appending the paths of the changed files you want to commit after `git commit -m "awesome commit"` - neat.
        kazinator 6y ago
        You can skip the explicit staging using git commit --patch then interactively select the specific changes by diff hunk. It combines with --amend.
    - erik_seaberg 6y ago
      Only the workspace can be built and tested, so the workspace is what should be committed. We should be stashing anything we don't want to test and commit yet.
      - kjeetgill 6y ago
- wk_end 6y ago
  Single data point, but I used hg for three years at work and never warmed up to it the way I've warmed up to git (and that's the "porcelain" too, I've never done a deep dive into the plumbing).
kazinator 6y ago
> I see this type of remark against git quite often on HN and I think it's exaggerated. Indeed, in more erudite forums with smarter users, more level-headed, less biased opinions of git circulate.

Joker_vD 6y ago

It's the command that does "Reset working directory/Discard changes/Revert to last commit"! You'd think that's what "git reset" would to, but of course not.

jlokier 6y ago
> You'd think that's what "git reset" would to, but of course not. Ahem, the command for "Reset working directory/Discard changes/Revert to last commit" is "git reset --hard". That's the one I use. "git checkout -f" does the same thing, but only because their different functionality coincides when there are no other arguments. When given a non-HEAD commit-id or branch-id they do different things.
- ArneBab 6y ago
  That’s a beautiful example of the problems of git :-)

dangoljames 6y ago

The one thing that all the negative commentary fails to acknowledge is that even in the face of this somewhat overstated inconsistency across all these command line tools and applications, is that for the knowledgeable and motivated, it is quite simple to wrap the more complex invocations in simplified scripts or, at the other extreme, a completely functional native GUI. They also fail to acknowledge that contemporary unix, aka Linux in it's many derivations and flavors, is entirely malleable at the source code level by it's users. That is a feature provided by literally no other operating system that is deployable at scale, and is, in fact, the singular feature that drives it's adoption -- not only is it 'free', you can hack it together in any fashion you damn well please, and you can use it to build peer-grade native applications, typically with little more than a tip of the hat as 'overhead'. tl;DR: Some folks might miss the point because they are not sufficiently motivated to engage the *nix world with the degree of articulation required to tap into it's less than casually accessible capabilities.

Joker_vD 6y ago
Sigh. Why are there still lots, heaps, and tons of horrible, inhumane, broken legacy technology still around in active use? Because its users/proponents are "knowledgeable and motivated" enough to keep pushing through. Sort of a Stockholm syndrome of computing, really. My brain is really quite small compared to all the knowledge about computers that is out there. And my willpower too is very limited. So I would rather learn things I'd rather like to know, and be motivated to do things I'd rather get done instead of spending those precious resources of mine (and time! I will die in less than 25,000 days, that's a pretty small amount of time, you know) on something of dubious value.
- zdragnar 6y ago
  They are still around because, through historical accident, they are what everyone knows and uses. Making a special snowflake that fits your brain better is good for you, but not necessarily anyone else. Making something good for everyone will, almost inevitably, become a design-by-committee monstrosity that is as problematic as the tool being replaced. The truth is, I am skeptical that these tools can be replaced by something that requires no effort to learn. At least, for the tools we already have, if you dont want to learn them, you can roll the dice and copy / paste from google overflow.

u801e 6y ago

The fundamental assumption is that people will either ask how to do something, or read the documentation/manual. It's not that we'll try to figure out how something work by experimenting. When I first started using UNIX/Linux after learning the DOS shell, I never said that using commands like rm or mkdir were not intuitive and that it should be like using del or md instead. I just learned the different commands by reading through documentation.

thewebcount 6y ago
And what if you don't have anyone to ask? The article very clearly states why the documentation is useless for a beginner. Other OSes have a concept called forgiveness that allows you to easily reverse a change you made explicitly so that you can experiment with it and figure things out for yourself. The problem is that Unix fundamentally doesn't allow you to figure things out by yourself. You absolutely need either a manual (that you will never find if you haven't already been told how to find it), or you need to have someone you can ask questions to.

maistho 6y ago

git has added `git restore` and `git switch`, intended to replace `git checkout` :) https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch

WorldMaker 6y ago

In recent versions of git (since 2.23) the two main `git checkout` functions have been split into two newly supported dedicated commands: `git switch` and `git restore`. Of course the next step is unlearning `git checkout` muscle memory and moving to using `git switch` and `git restore` more regularly.

Animats 6y ago

Some time ago, some UI designer asked, on HN, for what open source program should they build a UI to establish their reputation. I suggested "git". That was rejected as too hard. They just wanted to put eye candy on a command, not have to rethink its relationship with the user.

barbarbar 6y ago
It was very good idea. Though perhaps establish reputation is probably not a good starting point.
cxr 6y ago
A few years back, a designer waded into the middle of the echochamber on some HN thread about inculcating people from other disciplines. They wrote that "as a designer" they did not consider Git (GitHub?) to be thoughtfully put together or well-suited for the kind of work they do or something like that. It was a short comment, about as long as that, and there was no flaw or faux pas or even anything incendiary about it. HN wasn't having it, though, and downvoted it mercilessly. (There were no responses to say why it had been downvoted; the subthread dead-ended there.) It's things like this that remind me of the now-infamous comment in the Dropbox thread. I didn't think at the time to bookmark it with my "hn sucks" tag, and over the past year or two, I've tried several times to find it again, for reasons similar to[1], but I've been unable to. 1. https://news.ycombinator.com/item?id=22991033 https://news.ycombinator.com/item?id=22991033
cercatrova 6y ago
Well they were a UI designer and not a UX designer.

mehrdadn 6y ago

I've had a lot of issues with git UI but git checkout seems among the more sane ones. Compared to how, say, git add can remove a file...