4 ms·

I don't understand why so many people seem to dislike git. But maybe in actuality it is not many people, as usually people who are discontent are the loudest.

by wsc981 3y ago

I don't understand why so many people seem to dislike git. But maybe in actuality it is not many people, as usually people who are discontent are the loudest. I used Mercurial in the past for a bit, and it was fine. But for me it doesn't seem to have any huge advantages over git, if any. And after so many years of experience using git, I know what workflows work well, how to resolve merge conflicts, how to revert to an old commit if something really gets messed up, etcetera. I don't see any other DVCS really being able to replace git in the short run and I wouldn't be surprised if git will stay number 1 for the following decennia, as in my opinion it's really great software. A DVCS really has to provide substantial benefits over git in order to replace git as the number 1 DVCS.

czscout 3y ago
The sheer functionality of git is amazing. The number of times I have encountered a new situation and used a previously unknown (to me) feature, or (equally as impressive) been able to harness the flexibility of the software to wrangle some strange edge case are innumerable. All that while also being lightning fast.
cmrdporcupine 3y ago
Git functionality is great. But the CLI just kind of grew in a nonsensical way. No serious effort seems to have been made on UX consistency and verb/noun names. People who've been using it for years don't notice, they don't even think about it. But when coming from scratch, it's anything but intuitive. The CLI is not discoverable in a reasonable way. That and there's so many ways to use it. Mercurial had the advantage of having a much more consistent UX. Though these days I'm sure I'd struggle with it, because I'm so used to git. Mercurial was never trying to "replace" git. All of these guys came out at the same time. Git got headspace because Linux used it and GitHub was a "cool" Ruby on Rails site, run by cool web 2.0 kids, same era as the rise of Twitter, etc. (And also down all the time, just like Twitter).
- bigstrat2003 3y ago
  Exactly this. To be perfectly honest, the git CLI is so bad that I would take pretty much anything over git. I would prefer SVN over git, despite that product being older and with less functionality, just because it's at least easy to use. I learned and use git because that's just how the industry has moved, and I'm pragmatic enough to just roll with it. But good Lord, the UI is a case study in "programmers shouldn't be allowed to design UIs".
  - bvrmn 3y ago
    > I would prefer SVN over git Yes SVN has so much better CLI especially for things like * merging * history navigation * searching commit messages, filenames and file content * bisecting I'm filled with joy remembering good old SVN days and how my life was a way easier.
    - cmrdporcupine 3y ago
      Yeah, SVN was terrible. Its chief advantage was it was just less terrible than CVS and carried roughly the same workflow, so wasn't unfamiliar to people. It was basically CVS with atomic commits and a better interface and transport layer. You could drop SVN into a CVS shop without ruffling many feathers -- and back then I found most people were quite resistant to "novelty" in revision control systems, so SVN fit into that. I don't think there's anything intrinsically wrong with a centralized revision control system. I used Piper/CitC at Google for years and it could be ... tolerable. Many people just end up using git this way anyways. But SVN shipped with garbage merge-on-merge support, and that was the deal-breaker for me.
- mkesper 3y ago
  Please have a look at newer commands like restore, switch etc. Much clearer in my regard.
- WorldMaker 3y ago
  > Mercurial was never trying to "replace" git. All of these guys came out at the same time. Mercurial even had a couple weeks' head start on git, and git partly happened trying to replace Mercurial in early experimentation. The name "git" was always an interesting self-deprecating choice because it was (intentionally) "stupider" than its competition that it knew about, which included Mercurial (and also darcs/Monotone/Bazaar).
  - cmrdporcupine 3y ago
    It's a bummer that Graydon didn't stick with monotone.
speed_spread 3y ago
> after so many years This is why so many people dislike git. It's a base tool that should have an obvious workflow and very few pitfalls. Instead it allows one to do just about anything at anytime without giving much of a fuck about any resulting mess. All blade, no handle. It's a tool for Linus, by Linus. The average corporate coder is not Linus and doesn't have Linus problems. People don't want a Merkle tree manager, they want a workflow.
- replwoacause 3y ago
  Exactly…. (I strongly dislike git and much prefer KISS tools)
alex_smart 3y ago
Essentially, the problem with git is - it is a tool that is simple in its internals, but with a complex/confusing UI. The only way for someone to feel somewhat in comfortable with git is to have a good conceptual model for how it works internally. Once you have that mental model, you feel like a magician with git, but for beginners, it is a source of endless confusion and fear.
- G3rn0ti 3y ago
  GIT is a tool. Like a swiss army knife, it looks tricky and you need some experience to master all what it provides. But you never actually need everything and, surely, you should also shy away from features if you do not really need them. In this respect GIT is a bit like Perl or C++. You have to apply some discipline to avoid unnecessary complexity. Personally, I have never used GIT's "octopus" merge support but I am sure in some situation it may well be a useful feature to have. So I respect that while scratching my head. ;) Those are basically all commands I am really ever using: git status git add git rm git commit git branch git checkout -t -b ... git merge Learn those and you'll mostly good to go. Sure, I could to rebase my branches all day and make sure my version history looks "pretty" but I find obsessing with the commit history is a major source of complexity people face when using git. Another usual source of confusion is the branching model. However, that totally depends on your organization. GIT is flexible enough to support all kinds of weird development processes but if it comes over as complicated then don't put the blame on the tool but on its users.
  - knallfrosch 3y ago
    Although I understand all these commands and can use them, it's a typical Linux tool. Sure, if you understand the internals you can use the tools and the horrendous GUIs that are nothing more than a thin layer of paint. But a truly user-centric tool would actually help you with something like "I want to work on a new Feature A" "I want to continue working on Feature B" "I want my changes in the software/product" "I want to review a pull request (haha!) locally, in order to have IDE support." "I did an oopsie and need to go back." Imagine navigating to a website by specifing its hash, or seeing changes to a PowerPoint file using "git status" and seeing "++slide1.pp". It would be terrible.
IshKebab 3y ago
Aside from the terrible UI that several other people have mentioned, there are some other things that Git does badly (though I don't know if Mercurial does better): * Large projects. It has poor monorepo support (especially on Linux), and also poor multirepos support (submodules are really buggy). * Large files. LFS is a PoC-level hack; not a proper solution. * Conflict resolution. The default diff algorithm is very dumb, and even with `zdiff3` it doesn't quite give you enough information to easily resolve all conflicts.
- dig1 3y ago
  Git is very good with large repos, but the monorepo concept doesn't fit the git model. Monorepo is a bad idea with the current DVCS-es unless you use custom tooling. My guess is that people adopt monorepos because they aspire to be Google-scale, but it usually doesn't make sense for their workflow. If you want monorepo, use Perforce or SVN, but good luck with the speed ;)
  - IshKebab 3y ago
    > Git is very good with large repos Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it. > My guess is that people adopt monorepos because they aspire to be Google-scale, but it usually doesn't make sense for their workflow. Rubbish, it's nothing to do with wanting to be Google-scale. In fact being Google-scale makes a monorepo more difficult and require custom tooling. The reason people like monorepos is because they don't have the downsides of multirepos: * Cross-repo changes are very difficult to do and even harder to test. * Testing code becomes very difficult. For example if you update a library that's in one repo, how do you test all the things that depend on it? Very difficult with multirepos, trivial with monorepos. * Git's support for submodules is really bad. The downside of monorepos is that they are big and slow, but they work fine as long as you aren't Google scale.
    - dig1 3y ago
      > Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it. Which only proves my comment that git is not designed for bigcorp view of monorepos. Kernel is monorepo and works fine. > The reason people like monorepos is because they don't have the downsides of multirepos: The reason people like monorepos is that they are lazy to properly organize development process. If you update library in one repo but test it in another, I'd say you need to reconsider your pipeline. But, to each their own.
culebron21 3y ago
Despite having 14 years of experience with Git, I still can't use it without Stackoverflow for any non-daily task. And I've read the internals back in 2008 and understand this, but it doesn't make it any clear how merges, conflict resolution, or amendments to commits work. Absolutely confusing. In Mecrurial a lot more stuff is clear and easy to remember. Example: I tried rebasing or merging, and got merge conflicts. Started resolving them, git-added some of files, but got stuck, and want to get back to the last commit. git-reset doesn't work. How do I get there? No idea. How does the knowledge of commit hashes, branches and staging area help me? It doesn't.
- ilostmymangoman 3y ago
  When conflicts occur when performing rebase, git prints out the following: ``` hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm <conflicted_files>", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". ``` The options on how to proceed seem pretty clear to me.
  - culebron21 3y ago
    This is just one of a dozen unclear cases, that arise sometimes in git workflow. I do recall the first sentence in the hint, and I could have read the end too, but it's not clear, why it's "rebase --abort", not "reset --hard", that's why it's easy to forget this and other commands. Also, "git add/rm" is confusing, because they're not opposite of each other -- 'add' puts the file to the stage area, but rm removes it and makes forget.
rbehrends 3y ago
I could go into some detail here why Git is the harder to use system of the two, but I think that would miss the bigger point. IMO, the larger and longer-term problem is that (open source) version control systems seem to be mostly stuck in the early aughts. This may sound provocative, but in principle, Git and Mercurial don't offer much that wasn't already part of Monotone. Meta/Facebook has really been the only actor I am aware of who has been really pushing the envelope in terms of making open source version control more convenient. If you think I'm being needlessly provocative, just consider this simple example: why don't version control systems (especially ones that can change history) have undo/redo functionality out of the box? I've only seen this as a Facebook extension for Mercurial that never made it into the Mercurial proper (and survived only as part of Sapling). This is an essential feature of every basic editor nowadays and it is not easy to implement for a VCS, but it's still mind-boggling that after nearly two decades, it isn't considered core functionality of a VCS. Recovering from mistakes remains a pain point in pretty much any VCS, but shouldn't be. Commit graph visualization is another problem that's just not handled very well by either Git or Mercurial and hasn't really improved much since their early incarnations, if at all. "git log --graph" or "hg log -G" don't really produce output fit for human consumption if you have even a moderately complex branch structure. Version control systems are still generally very low-level, giving you a lot of primitives and very few high-level operations that aim at making complex workflows less complex.
- aseipp 3y ago
  > why don't version control systems (especially ones that can change history) have undo/redo functionality out of the box? It's true. And Jujutsu has undo functionality out of the box, too. It's not just Sapling. :) https://github.com/martinvonz/jj https://github.com/martinvonz/jj

by wsc981 3y ago

czscout 3y ago

The sheer functionality of git is amazing. The number of times I have encountered a new situation and used a previously unknown (to me) feature, or (equally as impressive) been able to harness the flexibility of the software to wrangle some strange edge case are innumerable. All that while also being lightning fast.

cmrdporcupine 3y ago

Git functionality is great. But the CLI just kind of grew in a nonsensical way. No serious effort seems to have been made on UX consistency and verb/noun names. People who've been using it for years don't notice, they don't even think about it. But when coming from scratch, it's anything but intuitive. The CLI is not discoverable in a reasonable way. That and there's so many ways to use it. Mercurial had the advantage of having a much more consistent UX. Though these days I'm sure I'd struggle with it, because I'm so used to git. Mercurial was never trying to "replace" git. All of these guys came out at the same time. Git got headspace because Linux used it and GitHub was a "cool" Ruby on Rails site, run by cool web 2.0 kids, same era as the rise of Twitter, etc. (And also down all the time, just like Twitter).

bigstrat2003 3y ago
Exactly this. To be perfectly honest, the git CLI is so bad that I would take pretty much anything over git. I would prefer SVN over git, despite that product being older and with less functionality, just because it's at least easy to use. I learned and use git because that's just how the industry has moved, and I'm pragmatic enough to just roll with it. But good Lord, the UI is a case study in "programmers shouldn't be allowed to design UIs".
- bvrmn 3y ago
  > I would prefer SVN over git Yes SVN has so much better CLI especially for things like * merging * history navigation * searching commit messages, filenames and file content * bisecting I'm filled with joy remembering good old SVN days and how my life was a way easier.
  - cmrdporcupine 3y ago
    Yeah, SVN was terrible. Its chief advantage was it was just less terrible than CVS and carried roughly the same workflow, so wasn't unfamiliar to people. It was basically CVS with atomic commits and a better interface and transport layer. You could drop SVN into a CVS shop without ruffling many feathers -- and back then I found most people were quite resistant to "novelty" in revision control systems, so SVN fit into that. I don't think there's anything intrinsically wrong with a centralized revision control system. I used Piper/CitC at Google for years and it could be ... tolerable. Many people just end up using git this way anyways. But SVN shipped with garbage merge-on-merge support, and that was the deal-breaker for me.
mkesper 3y ago
Please have a look at newer commands like restore, switch etc. Much clearer in my regard.
WorldMaker 3y ago
> Mercurial was never trying to "replace" git. All of these guys came out at the same time. Mercurial even had a couple weeks' head start on git, and git partly happened trying to replace Mercurial in early experimentation. The name "git" was always an interesting self-deprecating choice because it was (intentionally) "stupider" than its competition that it knew about, which included Mercurial (and also darcs/Monotone/Bazaar).
- cmrdporcupine 3y ago
  It's a bummer that Graydon didn't stick with monotone.

speed_spread 3y ago

> after so many years This is why so many people dislike git. It's a base tool that should have an obvious workflow and very few pitfalls. Instead it allows one to do just about anything at anytime without giving much of a fuck about any resulting mess. All blade, no handle. It's a tool for Linus, by Linus. The average corporate coder is not Linus and doesn't have Linus problems. People don't want a Merkle tree manager, they want a workflow.

replwoacause 3y ago
Exactly…. (I strongly dislike git and much prefer KISS tools)

alex_smart 3y ago

Essentially, the problem with git is - it is a tool that is simple in its internals, but with a complex/confusing UI. The only way for someone to feel somewhat in comfortable with git is to have a good conceptual model for how it works internally. Once you have that mental model, you feel like a magician with git, but for beginners, it is a source of endless confusion and fear.

G3rn0ti 3y ago
GIT is a tool. Like a swiss army knife, it looks tricky and you need some experience to master all what it provides. But you never actually need everything and, surely, you should also shy away from features if you do not really need them. In this respect GIT is a bit like Perl or C++. You have to apply some discipline to avoid unnecessary complexity. Personally, I have never used GIT's "octopus" merge support but I am sure in some situation it may well be a useful feature to have. So I respect that while scratching my head. ;) Those are basically all commands I am really ever using: git status git add git rm git commit git branch git checkout -t -b ... git merge Learn those and you'll mostly good to go. Sure, I could to rebase my branches all day and make sure my version history looks "pretty" but I find obsessing with the commit history is a major source of complexity people face when using git. Another usual source of confusion is the branching model. However, that totally depends on your organization. GIT is flexible enough to support all kinds of weird development processes but if it comes over as complicated then don't put the blame on the tool but on its users.
- knallfrosch 3y ago
  Although I understand all these commands and can use them, it's a typical Linux tool. Sure, if you understand the internals you can use the tools and the horrendous GUIs that are nothing more than a thin layer of paint. But a truly user-centric tool would actually help you with something like "I want to work on a new Feature A" "I want to continue working on Feature B" "I want my changes in the software/product" "I want to review a pull request (haha!) locally, in order to have IDE support." "I did an oopsie and need to go back." Imagine navigating to a website by specifing its hash, or seeing changes to a PowerPoint file using "git status" and seeing "++slide1.pp". It would be terrible.

IshKebab 3y ago

Aside from the terrible UI that several other people have mentioned, there are some other things that Git does badly (though I don't know if Mercurial does better): * Large projects. It has poor monorepo support (especially on Linux), and also poor multirepos support (submodules are really buggy). * Large files. LFS is a PoC-level hack; not a proper solution. * Conflict resolution. The default diff algorithm is very dumb, and even with `zdiff3` it doesn't quite give you enough information to easily resolve all conflicts.

dig1 3y ago
Git is very good with large repos, but the monorepo concept doesn't fit the git model. Monorepo is a bad idea with the current DVCS-es unless you use custom tooling. My guess is that people adopt monorepos because they aspire to be Google-scale, but it usually doesn't make sense for their workflow. If you want monorepo, use Perforce or SVN, but good luck with the speed ;)
- IshKebab 3y ago
  > Git is very good with large repos Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it. > My guess is that people adopt monorepos because they aspire to be Google-scale, but it usually doesn't make sense for their workflow. Rubbish, it's nothing to do with wanting to be Google-scale. In fact being Google-scale makes a monorepo more difficult and require custom tooling. The reason people like monorepos is because they don't have the downsides of multirepos: * Cross-repo changes are very difficult to do and even harder to test. * Testing code becomes very difficult. For example if you update a library that's in one repo, how do you test all the things that depend on it? Very difficult with multirepos, trivial with monorepos. * Git's support for submodules is really bad. The downside of monorepos is that they are big and slow, but they work fine as long as you aren't Google scale.
  - dig1 3y ago
    > Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it. Which only proves my comment that git is not designed for bigcorp view of monorepos. Kernel is monorepo and works fine. > The reason people like monorepos is because they don't have the downsides of multirepos: The reason people like monorepos is that they are lazy to properly organize development process. If you update library in one repo but test it in another, I'd say you need to reconsider your pipeline. But, to each their own.

culebron21 3y ago

Despite having 14 years of experience with Git, I still can't use it without Stackoverflow for any non-daily task. And I've read the internals back in 2008 and understand this, but it doesn't make it any clear how merges, conflict resolution, or amendments to commits work. Absolutely confusing. In Mecrurial a lot more stuff is clear and easy to remember. Example: I tried rebasing or merging, and got merge conflicts. Started resolving them, git-added some of files, but got stuck, and want to get back to the last commit. git-reset doesn't work. How do I get there? No idea. How does the knowledge of commit hashes, branches and staging area help me? It doesn't.

ilostmymangoman 3y ago
When conflicts occur when performing rebase, git prints out the following: ``` hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm <conflicted_files>", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". ``` The options on how to proceed seem pretty clear to me.
- culebron21 3y ago
  This is just one of a dozen unclear cases, that arise sometimes in git workflow. I do recall the first sentence in the hint, and I could have read the end too, but it's not clear, why it's "rebase --abort", not "reset --hard", that's why it's easy to forget this and other commands. Also, "git add/rm" is confusing, because they're not opposite of each other -- 'add' puts the file to the stage area, but rm removes it and makes forget.

rbehrends 3y ago

I could go into some detail here why Git is the harder to use system of the two, but I think that would miss the bigger point. IMO, the larger and longer-term problem is that (open source) version control systems seem to be mostly stuck in the early aughts. This may sound provocative, but in principle, Git and Mercurial don't offer much that wasn't already part of Monotone. Meta/Facebook has really been the only actor I am aware of who has been really pushing the envelope in terms of making open source version control more convenient. If you think I'm being needlessly provocative, just consider this simple example: why don't version control systems (especially ones that can change history) have undo/redo functionality out of the box? I've only seen this as a Facebook extension for Mercurial that never made it into the Mercurial proper (and survived only as part of Sapling). This is an essential feature of every basic editor nowadays and it is not easy to implement for a VCS, but it's still mind-boggling that after nearly two decades, it isn't considered core functionality of a VCS. Recovering from mistakes remains a pain point in pretty much any VCS, but shouldn't be. Commit graph visualization is another problem that's just not handled very well by either Git or Mercurial and hasn't really improved much since their early incarnations, if at all. "git log --graph" or "hg log -G" don't really produce output fit for human consumption if you have even a moderately complex branch structure. Version control systems are still generally very low-level, giving you a lot of primitives and very few high-level operations that aim at making complex workflows less complex.

aseipp 3y ago
> why don't version control systems (especially ones that can change history) have undo/redo functionality out of the box? It's true. And Jujutsu has undo functionality out of the box, too. It's not just Sapling. :) https://github.com/martinvonz/jj https://github.com/martinvonz/jj