5 ms·

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 solut

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
    > Because maybe mercurial's real problems wouldn't show up until people started using it at scale. I actually tried both git and mercurial almost a decade ago having had only experience with subversion, and found git to be much easier to understand and use. I don't recall what those pain points were, and am sure I couldn't describe them correctly if I did remember, but because of that I do expect such things to start popping up if more people used it.
- pseudalopex 5y ago
  Mercurial scaled better actually. It's 1 of the reasons Sun, Mozilla, and Facebook used it instead of Git. Typically Git was a bit faster for most operations on Linux. Mercurial was a bit faster for other operations. Especially on Windows. And both were much faster than the rest. Bitbucket and GitHub started around the same time. GitHub just executed better.
daxelrod 5y ago
I agree that collaborative text editing between multiple users simultaneously is hard. That doesn't mean that Git couldn't have a much better UI for this problem than it does. And while I agree that Git seems to have mostly won over SVN and Hg, it doesn't follow that it's because of its UI. (For example, I think that a lot of Git's success actually comes from the UI of GitHub, not Git itself, but I don't have evidence to back it up.) Take a look at the Research section at the bottom of https://gitless.com/ https://gitless.com/ for work that's been done on how to accomplish the same operations with a simpler conceptual model.
- lanstin 5y ago
  This is the real interesting problem. Even simple subtle decisions like "should this list be kept sorted, or have new things added to the end" determine under what conditions you will hit a new conflict and when you won't. List of enums, add to the end, and if 2 branches grab the next enum value then you'll see a conflict. List of lets say URL prefixes keep in order, then most randomly added URL prefixes will not collide or conflict, only conflicting if you get 2 things trying to operate on the same prefix.
- FractalHQ 5y ago
  Wow. Reading the home page of gitless made me both excited to use it and angry at how poorly designed git’s UI and UX are. Thanks for sharing this!
vxNsr 5y ago
GitHub is what made git so popular, git wasn’t inevitable, and GitHub didn’t become huge because of git, GitHub’s big innovation was attaching a social network to a software/code repo. It’s what made it way more popular than basically all the competition, which were just software/code repos but didn’t have a great network/social story. (Also at the time GitHub was coming out, the biggest player in the space decided to monetize in an annoying way.)
cellularmitosis 5y ago
> 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. Well, actually, a lot of people work in large repos, so this can be a pain. Which of course brings up another failing of the git UI: the difficulty of removing old history from the repo. Last I checked, you pretty much have to use a 3rd party tool for this.

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
  > Because maybe mercurial's real problems wouldn't show up until people started using it at scale. I actually tried both git and mercurial almost a decade ago having had only experience with subversion, and found git to be much easier to understand and use. I don't recall what those pain points were, and am sure I couldn't describe them correctly if I did remember, but because of that I do expect such things to start popping up if more people used it.
pseudalopex 5y ago
Mercurial scaled better actually. It's 1 of the reasons Sun, Mozilla, and Facebook used it instead of Git. Typically Git was a bit faster for most operations on Linux. Mercurial was a bit faster for other operations. Especially on Windows. And both were much faster than the rest. Bitbucket and GitHub started around the same time. GitHub just executed better.

daxelrod 5y ago

I agree that collaborative text editing between multiple users simultaneously is hard. That doesn't mean that Git couldn't have a much better UI for this problem than it does. And while I agree that Git seems to have mostly won over SVN and Hg, it doesn't follow that it's because of its UI. (For example, I think that a lot of Git's success actually comes from the UI of GitHub, not Git itself, but I don't have evidence to back it up.) Take a look at the Research section at the bottom of https://gitless.com/ https://gitless.com/ for work that's been done on how to accomplish the same operations with a simpler conceptual model.

lanstin 5y ago
This is the real interesting problem. Even simple subtle decisions like "should this list be kept sorted, or have new things added to the end" determine under what conditions you will hit a new conflict and when you won't. List of enums, add to the end, and if 2 branches grab the next enum value then you'll see a conflict. List of lets say URL prefixes keep in order, then most randomly added URL prefixes will not collide or conflict, only conflicting if you get 2 things trying to operate on the same prefix.
FractalHQ 5y ago
Wow. Reading the home page of gitless made me both excited to use it and angry at how poorly designed git’s UI and UX are. Thanks for sharing this!

vxNsr 5y ago

GitHub is what made git so popular, git wasn’t inevitable, and GitHub didn’t become huge because of git, GitHub’s big innovation was attaching a social network to a software/code repo. It’s what made it way more popular than basically all the competition, which were just software/code repos but didn’t have a great network/social story. (Also at the time GitHub was coming out, the biggest player in the space decided to monetize in an annoying way.)

cellularmitosis 5y ago

> 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. Well, actually, a lot of people work in large repos, so this can be a pain. Which of course brings up another failing of the git UI: the difficulty of removing old history from the repo. Last I checked, you pretty much have to use a 3rd party tool for this.