5 ms·

I don't know anything about Fossil, but saying that no one understands Git just makes me think they're ignorant to learning Git. I doubt that's the case, but st

I don't know anything about Fossil, but saying that no one understands Git just makes me think they're ignorant to learning Git. I doubt that's the case, but still, why say that?

crispyporkbites 9y ago
Because most users of git don’t really understand it. It’s really hard to learn properly and so most users just memorize the commands for their project’s workflow and ask the resident git expert to help (or nuke their local copy) when things go wrong.
- philwelch 9y ago
  It’s not hard to “really understand Git”. If anything, it’s the opposite problem—Git’s implementation is conceptually simple enough that the only good mental model the end user could possibly have is the implementation model. Systems like Subversion or Perforce or Fossil probably have even more complicated implementations than Git, and largely that’s to support a dumbed-down mental model that doesn’t require learning how the tool actually works. With Git, you learn how it works and you’re set, more or less.
  - ropeadopepope 9y ago
    > It’s not hard to “really understand Git”. Are you going to tell me you've never lost work because you didn't know git well enough to avoid putting your branch into a bad state?
    - philwelch 9y ago
      I’ve never lost work that I committed, which is the most you can ask of a version control system.
      - ropeadopepope 9y ago
        You've never botched a merge, try to undo it and accidentally lost work? It's happened to me and/or the people I work with roughly once a quarter since I started using git.
        rossy 9y ago
        You shouldn't be able to lose any committed work in git. If you botch a merge, you can reset to one of the merge parents and try it again. If you botch a "destructive" operation like a reset or a rebase, you can undo it using the reflog, which is essentially a 30-day undo history for every branch in your repository.
        mkgolden 9y ago
        Care to share a botched merge story of yours? I try to learn from others mistakes.
        plorkyeran 9y ago
        No, I can't say that I've ever lost work in that manner in over a decade of using git. The first few times I made a mess of things while trying to do a nontrivial merge it admittedly took a while to figure out how to get back to my starting point, but I guessed (correctly) that it'd be worth spending that time to learn how to do it rather than giving up and throwing away work.
      - _ph_ 9y ago
        No, I would ask also, that I routinely manage to commit successfully what I change vs. losing my changes when trying to commit them.
        philwelch 9y ago
        Fair—that hasn’t happened to me either, though.
blattimwind 9y ago
Because the data model of git and what git actually does has virtually nothing to do with how most people think it works, conversely the limitations of the tools are not well understood and users are seldom able to help themselves. The arcane git options, error messages and documentation are not overly helpful regarding this.
ezequiel-garzon 9y ago
I believe they’re saying that half-jokingly considering it’s illustrated by a cartoon: https://xkcd.com/1597/ https://xkcd.com/1597/
- SQLite 9y ago
  Indeed, that was then intent. The other points are serious, but then I thought "let's throw in a cartoon!" I just wrote the referenced article last night. Normally, I takes months or years before something like this gets picked up and discussed on HN, and I have more time to refine the text. This one snuck up on me. Come back in a month or two and the article will probably be much improved. You are reading an initial draft. On the other hand - it is a funny cartoon, don't you think? And it does kind of capture how most people use Git in a snarky kind of way, doesn't it? :-)
  - ezequiel-garzon 9y ago
    Absolutely, xkcd tends to reflect popular sentiment very well. On a different front, you made my day! One reply, and from the creator of SQLite, no less!
asah 9y ago
because it's true.
psyc 9y ago
Obviously it isn't literal. Myself and many of my colleagues have had confession sessions in which we all admit to regularly shooting ourselves in the foot with git, and needing to have a cheat sheet open, perpetually. That should tell you something, and it really shouldn't tell you that we're willfully ignorant, unless you want to sound smug. Any system that has consistent-ish rules can be learned. The more rules, and the subtler they are, the harder it is to learn. Git's problem is that it is necessary to know how it really works, to avoid getting into a bad state. It's complicated enough that it is easier than it should be to get into a bad state. The extent of the rules you have to know to avoid trouble does not match the simplicity of the day to day operations you do on the repo.
therealdrag0 9y ago
I feel comfortable in git because I've mastered SourceTree. Even 'rebasing' regularly seems to put me in the 1% of users compared to coworkers I've seen over the last two jobs I've worked on. I've seen so many git blunders, and experienced them myself. It's the only thing I've tried since SVN days, but I can totally see the room for alternatives...

I don't know anything about Fossil, but saying that no one understands Git just makes me think they're ignorant to learning Git. I doubt that's the case, but still, why say that?

crispyporkbites 9y ago

Because most users of git don’t really understand it. It’s really hard to learn properly and so most users just memorize the commands for their project’s workflow and ask the resident git expert to help (or nuke their local copy) when things go wrong.

philwelch 9y ago
It’s not hard to “really understand Git”. If anything, it’s the opposite problem—Git’s implementation is conceptually simple enough that the only good mental model the end user could possibly have is the implementation model. Systems like Subversion or Perforce or Fossil probably have even more complicated implementations than Git, and largely that’s to support a dumbed-down mental model that doesn’t require learning how the tool actually works. With Git, you learn how it works and you’re set, more or less.
- ropeadopepope 9y ago
  > It’s not hard to “really understand Git”. Are you going to tell me you've never lost work because you didn't know git well enough to avoid putting your branch into a bad state?
  - philwelch 9y ago
    I’ve never lost work that I committed, which is the most you can ask of a version control system.
    - ropeadopepope 9y ago
      You've never botched a merge, try to undo it and accidentally lost work? It's happened to me and/or the people I work with roughly once a quarter since I started using git.
      - rossy 9y ago
        You shouldn't be able to lose any committed work in git. If you botch a merge, you can reset to one of the merge parents and try it again. If you botch a "destructive" operation like a reset or a rebase, you can undo it using the reflog, which is essentially a 30-day undo history for every branch in your repository.
      - mkgolden 9y ago
        Care to share a botched merge story of yours? I try to learn from others mistakes.
      - plorkyeran 9y ago
        No, I can't say that I've ever lost work in that manner in over a decade of using git. The first few times I made a mess of things while trying to do a nontrivial merge it admittedly took a while to figure out how to get back to my starting point, but I guessed (correctly) that it'd be worth spending that time to learn how to do it rather than giving up and throwing away work.
    - _ph_ 9y ago
      No, I would ask also, that I routinely manage to commit successfully what I change vs. losing my changes when trying to commit them.
      - philwelch 9y ago
        Fair—that hasn’t happened to me either, though.

blattimwind 9y ago

Because the data model of git and what git actually does has virtually nothing to do with how most people think it works, conversely the limitations of the tools are not well understood and users are seldom able to help themselves. The arcane git options, error messages and documentation are not overly helpful regarding this.

ezequiel-garzon 9y ago

I believe they’re saying that half-jokingly considering it’s illustrated by a cartoon: https://xkcd.com/1597/ https://xkcd.com/1597/

SQLite 9y ago
Indeed, that was then intent. The other points are serious, but then I thought "let's throw in a cartoon!" I just wrote the referenced article last night. Normally, I takes months or years before something like this gets picked up and discussed on HN, and I have more time to refine the text. This one snuck up on me. Come back in a month or two and the article will probably be much improved. You are reading an initial draft. On the other hand - it is a funny cartoon, don't you think? And it does kind of capture how most people use Git in a snarky kind of way, doesn't it? :-)
- ezequiel-garzon 9y ago
  Absolutely, xkcd tends to reflect popular sentiment very well. On a different front, you made my day! One reply, and from the creator of SQLite, no less!

asah 9y ago

because it's true.

psyc 9y ago

Obviously it isn't literal. Myself and many of my colleagues have had confession sessions in which we all admit to regularly shooting ourselves in the foot with git, and needing to have a cheat sheet open, perpetually. That should tell you something, and it really shouldn't tell you that we're willfully ignorant, unless you want to sound smug. Any system that has consistent-ish rules can be learned. The more rules, and the subtler they are, the harder it is to learn. Git's problem is that it is necessary to know how it really works, to avoid getting into a bad state. It's complicated enough that it is easier than it should be to get into a bad state. The extent of the rules you have to know to avoid trouble does not match the simplicity of the day to day operations you do on the repo.

therealdrag0 9y ago

I feel comfortable in git because I've mastered SourceTree. Even 'rebasing' regularly seems to put me in the 1% of users compared to coworkers I've seen over the last two jobs I've worked on. I've seen so many git blunders, and experienced them myself. It's the only thing I've tried since SVN days, but I can totally see the room for alternatives...