5 ms·

No you're definitely not the only one. Git is one of the simplest and dumbest tools developers have at our disposal. People's inability to conceptualize a prett

No you're definitely not the only one. Git is one of the simplest and dumbest tools developers have at our disposal. People's inability to conceptualize a pretty straight forward graph is something no amount of shiny UI can ever fix. I don't understand HN's hardon for hating Git.

carussell 9y ago
Sure, and a piece table is a simple way to represent a file's contents. But if anyone wrote a shell or a text editor that required you to directly interact with the piece table to edit a file—instead of something sane—then they'd rightfully be called out on it. It wouldn't matter how much you argued about how simple the piece table is to understand, and it wouldn't matter how right you were about how simple the piece table is to understand. It's the wrong level of abstraction to expose in the UI.
- kadenshep 9y ago
  The only thing Git can really fix is changing it's command flags to be consistent across aliases/internal commands. That's about it. The whole point of an SCM is that graph that you want to move away from. People have asserted your claim many times but can't ever give specific things to fix about the "abstraction." There are about 5/6 fundamental operations you do in git/hg. If that's too much then again, there's not an abstraction that is going to help you out.
  - carussell 9y ago
    See, you're trying to foist a position on me that isn't mine—that I'm scared of the essential necessities of source control. And you act as if source control were invented with Git. Neither of these are true. > git/hg Mercurial was a great solution to the same problem that Git set out to tackle, virtually free of Git's foibles. The tradeoff was a few minor foibles of its own, but a much better tool. It's a fucking shame that Git managed to suck all the air out of the room, and we're left with a far, far worse industry standard.
    - kadenshep 9y ago
      >you're trying to foist a position on me that isn't mine I just said you can't give specifics on what to change, because there isn't much too change. >And you act as if source control were invented with Git No I'm not? >and we're left with a far, far worse industry standard. Yeah, we definitely should have gone with the system that can't do partial checkouts correctly or even roll things back. Branching name conflicts across remote repositories and bookmark fun! Git won for a reason, because it's good and sane at what it does.
      - pjmlp 9y ago
        That reason was called Linus and Linux kernel development. The master can do no wrong.
        AstralStorm 9y ago
        No, the reason is mercurial sucked at performance with many commits at the time, and was extra slow when merging. Lacked a few dubious features such as merging multiple branches at the same time too. It has improved but git is still noticeably more efficient with large repositories. (Almost straight comparison is any operation on Firefox repository vs its git port.)
        pjmlp 9y ago
        Mercurial has always been better than Git on Windows. Those dubious features are so relevant to daily work that I didn't even knew they existed.
        AstralStorm 9y ago
        Git main target is Linux. Obviously. Performance on the truly secondary platform was not relevant and it is mostly caused by slow lstat call. Instead Mercurial uses additional cache file which instead is slower on Linux with big repos. But happens to be faster in Windows. And the octopus merge is used by kernel maintainers sometimes if not quite a lot. That feature is impossible to add in Mercurial as it does not allow more than two commit parents.
  - eesmith 9y ago
    You wrote: People have asserted your claim many times but can't ever give specific things to fix about the "abstraction." That seems like you made an assertion as well. I think there are counter-examples. For example, the point of gitless is (quoting http://gitless.com/ http://gitless.com/ ): > Many people complain that Git is hard to use. We think the problem lies deeper than the user interface, in the concepts underlying Git. Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts Some commentary is at https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-conceptual-design-analysis/ https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-c... . Many HN discussions as well, including https://news.ycombinator.com/item?id=6927485 https://news.ycombinator.com/item?id=6927485 .
  - chriswarbo 9y ago
    > The whole point of an SCM is that graph that you want to move away from. I think that's an exaggeration. For example, Darcs and Pijul aren't based around a "graph of commits" like Git is, they use sets of inter-dependent patches instead. I'm sure there are other useful ways to model DVCS too. Whilst this is mostly irrelevant for Git users, you mentioned Mercurial so I thought I'd chime in :) > The only thing Git can really fix is changing it's command flags to be consistent across aliases/internal commands. I mostly agree with this: Git is widespread enough that it should mostly be kept stable; anything too drastic should be done in a separate project, either an "overlay", or a separate (possibly Git-compatible) DVCS.
    - kadenshep 9y ago
      >For example, Darcs and Pijul aren't based around a "graph of commits" like Git is, they use sets of inter-dependent patches instead. I said graph, I didn't say which graph. Both systems still use graphs. And still a graph you have to understand how to edit with each tool. The abstraction is still the same, and if you have problems with Git, you're going to have problems with either of those tools as well. The abstraction is not the problem, it's the developers inability to conceptualize the model in their head. Where is the exaggeration?
      - chriswarbo 9y ago
        > I said graph, I didn't say which graph You said "that graph" which, in context, I took to mean the git graph. > Both systems still use graphs True > The abstraction is still the same Not at all, since those graphs mean different things. Each makes some things easier and some things harder. For example, time is easy in git ("what did this look like last week?"). Changes are easy in Darcs ("does this conflict with that?"). Both tools allow the same sorts of things, but some are more natural than others. I think it's easy enough to use either as long as we think in its terms; learning to think in those terms may be hard. For git in particular, I think the CLI terminology doesn't help with that (e.g. "checkout"). > if you have problems with Git, you're going to have problems with either of those tools as well Not necessarily. As a simple example, some git operations "replay" a sequence of commits (e.g. cherrypicking). I've often had sequences which introduce something then later remove it (bugs, workarounds, stubs, etc.). If there's a merge conflict during the "replay", I'll have to spend time manually reintroducing those useless changes, just so i can resume the "replay" which will remove them again. From what I understand, in Darcs such changes would "cancel out" and not appear in the diff that we end up applying. > Where is the exaggeration? The idea that "uses a graph" implies "equally hard to use". The underlying datastructure != the abstraction; the semantics is much more important. For example, the forward/back buttons of a browser can be implemented as a linked list; blockchains are also linked lists, but that doesn't mean that they're both the same abstraction, or that understanding each takes the same level of knowledge/experience/etc.
sctb 9y ago
Could you please remove the thorniness and condescension for your posts? It breaks the guidelines and makes discussions worse. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- kadenshep 9y ago
  Can you tell the other guy to not post false and disingenuous statements? Because I'm pretty sure that is what degrades discussions, not any tone I choose to exhibit. I highly encourage you to read the thread thoroughly. If I switched my position on git we wouldn't be having this discussion, as evidenced elsewhere in the thread where people are taking a notably blunter tone than I am just with the side with popular support on this forum. I posted a bald statement. He replied directly with snide remarks and fallacies. Look at the timestamps and edits. I have every right to be annoyed and make it known that I am annoyed in my posts when the community refused to consistently adhere to guidelines. Enforce guidelines that keep discussions rational, not because people don't want to be accosted in public for their misleading, emotionally bloated statements.
  - sctb 9y ago
    It doesn't matter what you're replying to. The guidelines always apply, so please follow them.
    - kadenshep 9y ago
      >The guidelines always apply They are currently not being applied. Is it fair for me to point out how inconsistently the posts are being treated? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html: >Don't say things you wouldn't say face-to-face. Don't be snarky. "Every day humans make me again realize that I love my dogs, and respect my dogs, more than humans. There are exceptions but they are few and far between." [2] >Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. "Which sort of doesn't matter since everyone thinks GitHub is source management." [1] >Please don't post shallow dismissals "You all lost out on "the most sane and powerful" as a result." [1] "Calling it a sane and powerful source control tool is just not supported by the facts, calling "the most ..." is laughable." [1] "Calling Git sane just makes it clear that you haven't used a sane source management system." [1] "Lots of people are too busy/whatever to know what they are missing, maybe that's you. It's not me" [3] >When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." "Arguing with some random dude who thinks he knows more than me is not really fun." [3] "Dude, troll much?" [4] [1] https://news.ycombinator.com/item?id=16806588 https://news.ycombinator.com/item?id=16806588 [2] https://news.ycombinator.com/item?id=16807652 https://news.ycombinator.com/item?id=16807652 [3] https://news.ycombinator.com/item?id=16806877 https://news.ycombinator.com/item?id=16806877 [4] https://news.ycombinator.com/item?id=16807763 https://news.ycombinator.com/item?id=16807763 At least I had the decency to correct dishonest statements with vanilla citations in my posts, and they still got ignored.

carussell 9y ago

Sure, and a piece table is a simple way to represent a file's contents. But if anyone wrote a shell or a text editor that required you to directly interact with the piece table to edit a file—instead of something sane—then they'd rightfully be called out on it. It wouldn't matter how much you argued about how simple the piece table is to understand, and it wouldn't matter how right you were about how simple the piece table is to understand. It's the wrong level of abstraction to expose in the UI.

kadenshep 9y ago
The only thing Git can really fix is changing it's command flags to be consistent across aliases/internal commands. That's about it. The whole point of an SCM is that graph that you want to move away from. People have asserted your claim many times but can't ever give specific things to fix about the "abstraction." There are about 5/6 fundamental operations you do in git/hg. If that's too much then again, there's not an abstraction that is going to help you out.
- carussell 9y ago
  See, you're trying to foist a position on me that isn't mine—that I'm scared of the essential necessities of source control. And you act as if source control were invented with Git. Neither of these are true. > git/hg Mercurial was a great solution to the same problem that Git set out to tackle, virtually free of Git's foibles. The tradeoff was a few minor foibles of its own, but a much better tool. It's a fucking shame that Git managed to suck all the air out of the room, and we're left with a far, far worse industry standard.
  - kadenshep 9y ago
    >you're trying to foist a position on me that isn't mine I just said you can't give specifics on what to change, because there isn't much too change. >And you act as if source control were invented with Git No I'm not? >and we're left with a far, far worse industry standard. Yeah, we definitely should have gone with the system that can't do partial checkouts correctly or even roll things back. Branching name conflicts across remote repositories and bookmark fun! Git won for a reason, because it's good and sane at what it does.
    - pjmlp 9y ago
      That reason was called Linus and Linux kernel development. The master can do no wrong.
      - AstralStorm 9y ago
        No, the reason is mercurial sucked at performance with many commits at the time, and was extra slow when merging. Lacked a few dubious features such as merging multiple branches at the same time too. It has improved but git is still noticeably more efficient with large repositories. (Almost straight comparison is any operation on Firefox repository vs its git port.)
        pjmlp 9y ago
        Mercurial has always been better than Git on Windows. Those dubious features are so relevant to daily work that I didn't even knew they existed.
        AstralStorm 9y ago
        Git main target is Linux. Obviously. Performance on the truly secondary platform was not relevant and it is mostly caused by slow lstat call. Instead Mercurial uses additional cache file which instead is slower on Linux with big repos. But happens to be faster in Windows. And the octopus merge is used by kernel maintainers sometimes if not quite a lot. That feature is impossible to add in Mercurial as it does not allow more than two commit parents.
- eesmith 9y ago
  You wrote: People have asserted your claim many times but can't ever give specific things to fix about the "abstraction." That seems like you made an assertion as well. I think there are counter-examples. For example, the point of gitless is (quoting http://gitless.com/ http://gitless.com/ ): > Many people complain that Git is hard to use. We think the problem lies deeper than the user interface, in the concepts underlying Git. Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts Some commentary is at https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-conceptual-design-analysis/ https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-c... . Many HN discussions as well, including https://news.ycombinator.com/item?id=6927485 https://news.ycombinator.com/item?id=6927485 .
- chriswarbo 9y ago
  > The whole point of an SCM is that graph that you want to move away from. I think that's an exaggeration. For example, Darcs and Pijul aren't based around a "graph of commits" like Git is, they use sets of inter-dependent patches instead. I'm sure there are other useful ways to model DVCS too. Whilst this is mostly irrelevant for Git users, you mentioned Mercurial so I thought I'd chime in :) > The only thing Git can really fix is changing it's command flags to be consistent across aliases/internal commands. I mostly agree with this: Git is widespread enough that it should mostly be kept stable; anything too drastic should be done in a separate project, either an "overlay", or a separate (possibly Git-compatible) DVCS.
  - kadenshep 9y ago
    >For example, Darcs and Pijul aren't based around a "graph of commits" like Git is, they use sets of inter-dependent patches instead. I said graph, I didn't say which graph. Both systems still use graphs. And still a graph you have to understand how to edit with each tool. The abstraction is still the same, and if you have problems with Git, you're going to have problems with either of those tools as well. The abstraction is not the problem, it's the developers inability to conceptualize the model in their head. Where is the exaggeration?
    - chriswarbo 9y ago
      > I said graph, I didn't say which graph You said "that graph" which, in context, I took to mean the git graph. > Both systems still use graphs True > The abstraction is still the same Not at all, since those graphs mean different things. Each makes some things easier and some things harder. For example, time is easy in git ("what did this look like last week?"). Changes are easy in Darcs ("does this conflict with that?"). Both tools allow the same sorts of things, but some are more natural than others. I think it's easy enough to use either as long as we think in its terms; learning to think in those terms may be hard. For git in particular, I think the CLI terminology doesn't help with that (e.g. "checkout"). > if you have problems with Git, you're going to have problems with either of those tools as well Not necessarily. As a simple example, some git operations "replay" a sequence of commits (e.g. cherrypicking). I've often had sequences which introduce something then later remove it (bugs, workarounds, stubs, etc.). If there's a merge conflict during the "replay", I'll have to spend time manually reintroducing those useless changes, just so i can resume the "replay" which will remove them again. From what I understand, in Darcs such changes would "cancel out" and not appear in the diff that we end up applying. > Where is the exaggeration? The idea that "uses a graph" implies "equally hard to use". The underlying datastructure != the abstraction; the semantics is much more important. For example, the forward/back buttons of a browser can be implemented as a linked list; blockchains are also linked lists, but that doesn't mean that they're both the same abstraction, or that understanding each takes the same level of knowledge/experience/etc.

sctb 9y ago

Could you please remove the thorniness and condescension for your posts? It breaks the guidelines and makes discussions worse. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

kadenshep 9y ago
Can you tell the other guy to not post false and disingenuous statements? Because I'm pretty sure that is what degrades discussions, not any tone I choose to exhibit. I highly encourage you to read the thread thoroughly. If I switched my position on git we wouldn't be having this discussion, as evidenced elsewhere in the thread where people are taking a notably blunter tone than I am just with the side with popular support on this forum. I posted a bald statement. He replied directly with snide remarks and fallacies. Look at the timestamps and edits. I have every right to be annoyed and make it known that I am annoyed in my posts when the community refused to consistently adhere to guidelines. Enforce guidelines that keep discussions rational, not because people don't want to be accosted in public for their misleading, emotionally bloated statements.
- sctb 9y ago
  It doesn't matter what you're replying to. The guidelines always apply, so please follow them.
  - kadenshep 9y ago
    >The guidelines always apply They are currently not being applied. Is it fair for me to point out how inconsistently the posts are being treated? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html: >Don't say things you wouldn't say face-to-face. Don't be snarky. "Every day humans make me again realize that I love my dogs, and respect my dogs, more than humans. There are exceptions but they are few and far between." [2] >Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. "Which sort of doesn't matter since everyone thinks GitHub is source management." [1] >Please don't post shallow dismissals "You all lost out on "the most sane and powerful" as a result." [1] "Calling it a sane and powerful source control tool is just not supported by the facts, calling "the most ..." is laughable." [1] "Calling Git sane just makes it clear that you haven't used a sane source management system." [1] "Lots of people are too busy/whatever to know what they are missing, maybe that's you. It's not me" [3] >When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." "Arguing with some random dude who thinks he knows more than me is not really fun." [3] "Dude, troll much?" [4] [1] https://news.ycombinator.com/item?id=16806588 https://news.ycombinator.com/item?id=16806588 [2] https://news.ycombinator.com/item?id=16807652 https://news.ycombinator.com/item?id=16807652 [3] https://news.ycombinator.com/item?id=16806877 https://news.ycombinator.com/item?id=16806877 [4] https://news.ycombinator.com/item?id=16807763 https://news.ycombinator.com/item?id=16807763 At least I had the decency to correct dishonest statements with vanilla citations in my posts, and they still got ignored.