8 ms·

I'm sorry, but how many bits of git's UI do we have to force users to manually replace before we realize that the entire problem is git's UI? Between the tone

I'm sorry, but how many bits of git's UI do we have to force users to manually replace before we realize that the entire problem is git's UI? Between the tone deaf responses here about "using a GUI client is the problem," to the tone deaf responses of "you just have to learn it's internal architecture," it should be obvious what the problem is. The problem is not just being able to undo a mistake (though that's certainly one of the problems). Git is an incredibly user-hostile experience, and someone needs to fix or replace it. Can we just say it out loud and stop pretending that the problem is the literally thousands of users who have problems using it?

sloucher 5y ago
Last time I checked, 5 of the top 10 questions on StackOverflow were about Git...
- adamrezich 5y ago
  still true! but that isn't a great metric necessarily, as #10 is "What is the “-->” operator in C/C++?" https://stackoverflow.com/questions/1642028/what-is-the-operator-in-c-c https://stackoverflow.com/questions/1642028/what-is-the-oper... which is just a novelty rather than a common question
- greenshackle2 5y ago
  Maybe because like 90% of devs use git; there's no language or framework that is used by so many.
nexuist 5y ago
The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases. Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this happens daily either. In the rare case that someone hoses remote, yes you'll have to do some weird git-fu to get everyone working again, but it's really hard to hose remote if you stick to the pull -> commit -> push -> merge pattern, which is what 99% of users are doing anyways. I've used git for 9 years and I've never had to spend longer than an hour troubleshooting git based BS. And if you'll remember, 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before.
- chriswarbo 5y ago
  > It's a human problem If it were a human problem, how could alternatives like Mercurial and Darcs get consistent amounts of praise for their intuitive workflows? > 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before. SVN isn't distributed; it mostly tried to replace CVS, which it managed to do very successfully. As for DVCS, the fact that system X became more popular than system Y doesn't mean that every aspect of X is better than Y. Many would say git succeeded despite its awful interface. As far as I can tell, the main feature of git was its speed; that made it usable for huge projects like Linux and Xorg, and this endorsement from high-profile projects gave git the edge for DVCS hosting sites like Gitorious. Then GitHub came along, and grew into such a behemoth that git became the de facto standard. See also: WorseIsBetter
  - umvi 5y ago
    > If it were a human problem, how could alternatives like Mercurial and Darcs get consistent amounts of praise for their intuitive workflows? Because maybe mercurial's real problems wouldn't show up until people started using it at scale. This is a classic problem that happens time and again. Windows vs. Mac back in 2005: "Windows having malware is a human problem" "If it were a human problem, how could alternatives like Mac get consistent amounts of praise for their lack of malware?" Turns out it's just because Mac didn't have a big enough market share. As soon as it did, Apple could no longer claim that Macs can't get malware because they can and do. Similarly, if you scaled up the number of Mercurial users by several orders of magnitude so that it was now "mainstream", I'm sure some of its lesser known pain points and/or counter intuitive behaviors would start floating up to the top 10 HN stories. But since hardly anyone uses Mercurial vs. Git, that doesn't happen. Just because a minority of users praise something (<insert lesser known language>, <insert lesser known DB>, <insert lesser known VCS>, etc.) doesn't mean if you scaled up the userbase one or more magnitudes it would continue getting that level of praise from all users.
    - Izkata 5y ago
quickthrower2 5y ago
I feel that I only understand git because I’m forced to use it for years, but the experience could have been a lot less painful. I use a GUI for sure. Do people really diff and resolve big conflicts at a command line? I never figured out how.
- rjmunro 5y ago
  Just delete the bits you don't want and `git add` It helps a lot to set: git config --global merge.conflictstyle diff3 then you can see the before as well as the 2 changes you are trying to resolve.
- cerved 5y ago
  git mergetool or git checkout --ours/theirs && git add .
rjmunro 5y ago
There is no doubt that a bunch of the general commands are really poorly named, or mixed together. `git checkout branch` means switch to a branch - that's fine. But `git checkout filename` means "undo changes to the file". What? That's totally insane. `git branch new-branch-name` means create a new branch. Great, but it doesn't check out the branch, which you want like 99.9% of the time. If you want to do that, you use `git checkout -b new-branch-name`. Yes, a third separate use for git checkout. Why not (e.g.) `git branch -c new-branch-name` with a config option to make `-c` the default if you want it? If you rebase and push, it tells you to do a `git pull` to "fix" it, when in every workflow I've ever done, you want to add a `-f` and push away, just be aware that you are intentionally overwriting the remote branch.
- npteljes 5y ago
  And if I create a new branch locally, why must I specify what name I'd use for it on the remote? Why would I like an other name I wonder? It's fantastic that it can do this, but the default should be the branch name I'm using and that's that.
  - u801e 5y ago
    Are you referring to the git branch command? As far as I'm aware, you don't have to specify the name of the remote branch when creating a new local branch. And when you push to the remote, a branch with the same name is created by default. You would have to specify the remote branch name when running git push if you wanted a different name for the remote branch.
    - npteljes 5y ago
      My env doesn't do this. Here's what I did: git checkout -b test git push And I got "fatal: The current branch test has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin test" But in this situation, we actually push with "git push -u origin branchname". After deleting the "test" branch, I recreated it with "git branch test", switched to it and tried a push, and I got the same error message.
TobTobXX 5y ago
Admittedly I did spend like a combined hour troubleshooting git over the last two months. But git saved me an immeasurable amount of hours in return. I was asked what I worked on some specific week back in may -- git saved me. I had to look up what performance my program had before a specific change -- git saved me. I had to try stuff out without messing up my codebase -- git saved me. True, I invested quite a few hours and I still do, but I think the investment pays itself off. I'll never ever do a project without git.
deleted 5y ago
[deleted]
lawn 5y ago
This is the one thing I took with me from The Design of Everyday Things: usability design matters, and it matters a lot.
gumby 5y ago
> tone deaf responses of "you just have to learn it's internal architecture," Why is this tone deaf? It’s a development tool for programmers and the internal structure is conceptionally pretty straightforward. Understanding your tools is pretty much prerequisite. You don’t have to have written a compiler to use one, but you do have to have a model of what it does. Git is no different.
junon 5y ago
> Git is an incredibly user-hostile experience, and someone needs to fix or replace it. * in your opinion.

sloucher 5y ago

Last time I checked, 5 of the top 10 questions on StackOverflow were about Git...

adamrezich 5y ago
still true! but that isn't a great metric necessarily, as #10 is "What is the “-->” operator in C/C++?" https://stackoverflow.com/questions/1642028/what-is-the-operator-in-c-c https://stackoverflow.com/questions/1642028/what-is-the-oper... which is just a novelty rather than a common question
greenshackle2 5y ago
Maybe because like 90% of devs use git; there's no language or framework that is used by so many.

nexuist 5y ago

The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases. Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this happens daily either. In the rare case that someone hoses remote, yes you'll have to do some weird git-fu to get everyone working again, but it's really hard to hose remote if you stick to the pull -> commit -> push -> merge pattern, which is what 99% of users are doing anyways. I've used git for 9 years and I've never had to spend longer than an hour troubleshooting git based BS. And if you'll remember, 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before.

chriswarbo 5y ago
> It's a human problem If it were a human problem, how could alternatives like Mercurial and Darcs get consistent amounts of praise for their intuitive workflows? > 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before. SVN isn't distributed; it mostly tried to replace CVS, which it managed to do very successfully. As for DVCS, the fact that system X became more popular than system Y doesn't mean that every aspect of X is better than Y. Many would say git succeeded despite its awful interface. As far as I can tell, the main feature of git was its speed; that made it usable for huge projects like Linux and Xorg, and this endorsement from high-profile projects gave git the edge for DVCS hosting sites like Gitorious. Then GitHub came along, and grew into such a behemoth that git became the de facto standard. See also: WorseIsBetter
- umvi 5y ago
  > If it were a human problem, how could alternatives like Mercurial and Darcs get consistent amounts of praise for their intuitive workflows? Because maybe mercurial's real problems wouldn't show up until people started using it at scale. This is a classic problem that happens time and again. Windows vs. Mac back in 2005: "Windows having malware is a human problem" "If it were a human problem, how could alternatives like Mac get consistent amounts of praise for their lack of malware?" Turns out it's just because Mac didn't have a big enough market share. As soon as it did, Apple could no longer claim that Macs can't get malware because they can and do. Similarly, if you scaled up the number of Mercurial users by several orders of magnitude so that it was now "mainstream", I'm sure some of its lesser known pain points and/or counter intuitive behaviors would start floating up to the top 10 HN stories. But since hardly anyone uses Mercurial vs. Git, that doesn't happen. Just because a minority of users praise something (<insert lesser known language>, <insert lesser known DB>, <insert lesser known VCS>, etc.) doesn't mean if you scaled up the userbase one or more magnitudes it would continue getting that level of praise from all users.
  - Izkata 5y ago

quickthrower2 5y ago

I feel that I only understand git because I’m forced to use it for years, but the experience could have been a lot less painful. I use a GUI for sure. Do people really diff and resolve big conflicts at a command line? I never figured out how.

rjmunro 5y ago
Just delete the bits you don't want and `git add` It helps a lot to set: git config --global merge.conflictstyle diff3 then you can see the before as well as the 2 changes you are trying to resolve.
cerved 5y ago
git mergetool or git checkout --ours/theirs && git add .

rjmunro 5y ago

There is no doubt that a bunch of the general commands are really poorly named, or mixed together. `git checkout branch` means switch to a branch - that's fine. But `git checkout filename` means "undo changes to the file". What? That's totally insane. `git branch new-branch-name` means create a new branch. Great, but it doesn't check out the branch, which you want like 99.9% of the time. If you want to do that, you use `git checkout -b new-branch-name`. Yes, a third separate use for git checkout. Why not (e.g.) `git branch -c new-branch-name` with a config option to make `-c` the default if you want it? If you rebase and push, it tells you to do a `git pull` to "fix" it, when in every workflow I've ever done, you want to add a `-f` and push away, just be aware that you are intentionally overwriting the remote branch.

npteljes 5y ago
And if I create a new branch locally, why must I specify what name I'd use for it on the remote? Why would I like an other name I wonder? It's fantastic that it can do this, but the default should be the branch name I'm using and that's that.
- u801e 5y ago
  Are you referring to the git branch command? As far as I'm aware, you don't have to specify the name of the remote branch when creating a new local branch. And when you push to the remote, a branch with the same name is created by default. You would have to specify the remote branch name when running git push if you wanted a different name for the remote branch.
  - npteljes 5y ago
    My env doesn't do this. Here's what I did: git checkout -b test git push And I got "fatal: The current branch test has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin test" But in this situation, we actually push with "git push -u origin branchname". After deleting the "test" branch, I recreated it with "git branch test", switched to it and tried a push, and I got the same error message.

TobTobXX 5y ago

Admittedly I did spend like a combined hour troubleshooting git over the last two months. But git saved me an immeasurable amount of hours in return. I was asked what I worked on some specific week back in may -- git saved me. I had to look up what performance my program had before a specific change -- git saved me. I had to try stuff out without messing up my codebase -- git saved me. True, I invested quite a few hours and I still do, but I think the investment pays itself off. I'll never ever do a project without git.

deleted 5y ago

[deleted]

lawn 5y ago

This is the one thing I took with me from The Design of Everyday Things: usability design matters, and it matters a lot.

gumby 5y ago

> tone deaf responses of "you just have to learn it's internal architecture," Why is this tone deaf? It’s a development tool for programmers and the internal structure is conceptionally pretty straightforward. Understanding your tools is pretty much prerequisite. You don’t have to have written a compiler to use one, but you do have to have a model of what it does. Git is no different.

junon 5y ago

> Git is an incredibly user-hostile experience, and someone needs to fix or replace it. * in your opinion.