10 ms·

I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.

macjohnmcc 2y ago
And still shoot yourself in the foot.
verandaguy 2y ago
Eh, yes and no. Git porcelain stuff's plenty good for probably 95% of users. `rebase -i` comes with a guide on which commands do what, and you could write a couple of paragraphs about how to format `git log`'s output with your own preferences and tradeoffs -- and porcelain usually includes stuff as eclectic as `git gc`, `git fsck`, and `git rev-parse` by most accounts. Git plumbing's definitely a bit more obscure, and does a bunch of stuff on its own that you can't always easily do with porcelain commands because they're optimized for the common use cases. TL;DR: while Git's big (huge even), a lot of what it provides is way off the beaten path for most devs.
- ujkiolp 2y ago
  not my experience - almost always some edge case leads me to a git rabbit hole tldr: even if you never plan to use anything advanced, you’ll end up in some weird situation where you need to do something even if you’re in the “95% of the users” no shade, yes ofc you “could this, could that” to make things work and we have been stuck with this for so long that an alternative doesn’t even seem plausible
  - sampullman 2y ago
    I can't remember the last time I ended up in a weird situation, I stick to basic options with init,clone,fetch,checkout,branch,commit,rebase,remote,log,stash,cherry-pick,blame,config. It did take maybe a year or so to develop the mental model of the how commands map to the underlying structure of commits, and another few years to avoid footguns (like always "push --force-with-lease"). So I think it is probably too complicated and would be happy to switch to a better alternative if one comes up, but what seems really implausible to me is going back to the bad old days of SVN.
    - ujkiolp 2y ago
      >It did take maybe a year or so we have normalized this for git - a tool to store versions of text. That’s the problem
      - sampullman 2y ago
        A folder with a list of files is a tool to store versions of text. Git is somewhat more useful.
      - kortilla 2y ago
        Maybe you’re young, but git is better than all of the other shit before it. Try to come up with something simpler than git, and you’ll end up with something like SVN or CVS that struggled with more than a couple of people working on the same files. Try to make something that is more content aware, and you’ll find out how git got its name in the first place.
        nextaccountic 2y ago
        Mercurial is simpler than git. It is (or was) just too damn slow
        Izkata 2y ago
        For some people. Back when I only knew how to use subversion, I tried out both git and mercurial, and found mercurial confusing while git clicked immediately. Unfortunately it's been long enough I don't remember details why, just that it was something with how it handled branches.
        capitainenemo 2y ago
        Mercurial has both "real" branches (history is kept so you can always tell what revisions were in what branch) as well as git "branch is just a pointer tag" So really you can choose whatever suits your needs. Personally the things I love about mercurial are: more consistent commandline (that's the simple part others bring up) revsets (awesome query language for revisions, there's also filesets, but I don't use that as much) absorb (I think someone added a git extension that does something similar a few months ago) fa --deleted grep --all phases ♥
- rtldg 2y ago
  With 'gitk' I'm not sure I'll ever have to learn how to use 'git log'. A Good Enough preinstalled GUI is too convenient
ajross 2y ago
My sense, bluntly, is that if people spent half the effort learning git that they do whining about it, no one would bother making a 30+ part guide just explaining stuff you could find in a man page. Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index is a tiny proto-commit still in progress that you "add" to before committing. There. That's git. Want to know more? Don't read the guide, just google "how to I switch to a specific git commit without affecting my tree?", or "how do I commit only some of my changed files?", or "how to I copy this commit from another place into my current tree?". The base abstractions are minimalist and easy. The things you want to do with them are elaborate and complicated. Learn the former, google the latter. Don't read guides.
- skydhash 2y ago
  Or do read books and guides. But in an exploratory manner. So when you do have a need for a specific operation (which happens rarely) you have a mental map that can give you directions.
- chasil 2y ago
  The deal killer for me, the inescapable aspect of my users, is that they insist upon checking passwords into revision control. Because the C and PL/SQL people are on CVS, I can fix this with vi on the ,v archive. First on TFS repositories, and now with git grep I can easily find exposed passwords for many things. But it's just SQL Server! We will never be able to use git responsibly, so I will peruse this guide with academic interest. Don't even get me started on secrecy management. I am looking forward to retirement!
  - rblatz 2y ago
    The devs shouldn’t have access to prod credentials in the first place. That’s the real issue.
    - chasil 2y ago
20k 2y ago
Honestly, 99% of the pain of git is simply because people use it through the CLI. If you use tortoisegit or a visual tool, you don't need to worry about any of this because its self explanatory, and it becomes trivial to use Learning git like this is honestly just hampering yourself
- wruza 2y ago
  I’ve seen tortoise users break their repo, struggle to understand the issue and then push it through, making it everyone’s problem. Git language is screwed, you cannot unscrew it with a right-click gui because you basically click some latin-looking hieroglyphs that you don’t know either way.
  - globular-toast 2y ago
    I highly doubt tortoise or any tool can "break" a repo. This might be a sign that you don't understand git either. Now I'm sure it can lead to people who don't know what they're doing doing the wrong thing, but if they're allowed to push somewhere and make it someone else's problem, that's not their fault. They've been forced to use git, so there should be someone else who actually understands git.
    - _puk 2y ago
      Ah, we're holding it wrong. Got it.
    - wruza 2y ago
      “Break” doesn’t mean repo integrity corruption. It means that you try to merge a branch, and it shits itself with hundreds of conflicts that shouldn’t appear and/or has changes that may partially revert the progress made by other merges. if they're allowed to push somewhere and make it someone else's problem, that's not their fault What? This made zeroest sense of the day. Like, I should walk to their desk and check if a feature branch is okay to push or what?
      - 2y ago
ggregoire 2y ago
I can make a 5 line HN comment explaining how to use git: 1. git clone 2. git checkout 3. git pull 4. git add + commit + push 5. git reset / rebase
juped 2y ago
Why are programmers so vehemently angry over the fact that a complex tool which does complex things to a complex data structure might have some complexity to it?
- zanellato19 2y ago
  "I don't understand this complexity so this means it shouldn't exist"
  - keithalewis 2y ago
    Linus wrote it, so there's got to be a pony in there somewhere. He's the first person in the world to figure out version control software. /s
- solidasparagus 2y ago
  It's the de facto tool for our industry. For the vast majority of cases, users bear the burden of that complexity without gaining much benefit. And (at least for me) it doesn't guarantee the one thing I need it to do - make sure I can never lose progress.
- andrewflnr 2y ago
  The data structure isn't that complex. Most of the things we want to do to it aren't that complex. And yet... https://xkcd.com/1597 https://xkcd.com/1597

macjohnmcc 2y ago

And still shoot yourself in the foot.

verandaguy 2y ago

Eh, yes and no. Git porcelain stuff's plenty good for probably 95% of users. `rebase -i` comes with a guide on which commands do what, and you could write a couple of paragraphs about how to format `git log`'s output with your own preferences and tradeoffs -- and porcelain usually includes stuff as eclectic as `git gc`, `git fsck`, and `git rev-parse` by most accounts. Git plumbing's definitely a bit more obscure, and does a bunch of stuff on its own that you can't always easily do with porcelain commands because they're optimized for the common use cases. TL;DR: while Git's big (huge even), a lot of what it provides is way off the beaten path for most devs.

ujkiolp 2y ago
not my experience - almost always some edge case leads me to a git rabbit hole tldr: even if you never plan to use anything advanced, you’ll end up in some weird situation where you need to do something even if you’re in the “95% of the users” no shade, yes ofc you “could this, could that” to make things work and we have been stuck with this for so long that an alternative doesn’t even seem plausible
- sampullman 2y ago
  I can't remember the last time I ended up in a weird situation, I stick to basic options with init,clone,fetch,checkout,branch,commit,rebase,remote,log,stash,cherry-pick,blame,config. It did take maybe a year or so to develop the mental model of the how commands map to the underlying structure of commits, and another few years to avoid footguns (like always "push --force-with-lease"). So I think it is probably too complicated and would be happy to switch to a better alternative if one comes up, but what seems really implausible to me is going back to the bad old days of SVN.
  - ujkiolp 2y ago
    >It did take maybe a year or so we have normalized this for git - a tool to store versions of text. That’s the problem
    - sampullman 2y ago
      A folder with a list of files is a tool to store versions of text. Git is somewhat more useful.
    - kortilla 2y ago
      Maybe you’re young, but git is better than all of the other shit before it. Try to come up with something simpler than git, and you’ll end up with something like SVN or CVS that struggled with more than a couple of people working on the same files. Try to make something that is more content aware, and you’ll find out how git got its name in the first place.
      - nextaccountic 2y ago
        Mercurial is simpler than git. It is (or was) just too damn slow
        Izkata 2y ago
        For some people. Back when I only knew how to use subversion, I tried out both git and mercurial, and found mercurial confusing while git clicked immediately. Unfortunately it's been long enough I don't remember details why, just that it was something with how it handled branches.
        capitainenemo 2y ago
        Mercurial has both "real" branches (history is kept so you can always tell what revisions were in what branch) as well as git "branch is just a pointer tag" So really you can choose whatever suits your needs. Personally the things I love about mercurial are: more consistent commandline (that's the simple part others bring up) revsets (awesome query language for revisions, there's also filesets, but I don't use that as much) absorb (I think someone added a git extension that does something similar a few months ago) fa --deleted grep --all phases ♥
rtldg 2y ago
With 'gitk' I'm not sure I'll ever have to learn how to use 'git log'. A Good Enough preinstalled GUI is too convenient

ajross 2y ago

My sense, bluntly, is that if people spent half the effort learning git that they do whining about it, no one would bother making a 30+ part guide just explaining stuff you could find in a man page. Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index is a tiny proto-commit still in progress that you "add" to before committing. There. That's git. Want to know more? Don't read the guide, just google "how to I switch to a specific git commit without affecting my tree?", or "how do I commit only some of my changed files?", or "how to I copy this commit from another place into my current tree?". The base abstractions are minimalist and easy. The things you want to do with them are elaborate and complicated. Learn the former, google the latter. Don't read guides.

skydhash 2y ago
Or do read books and guides. But in an exploratory manner. So when you do have a need for a specific operation (which happens rarely) you have a mental map that can give you directions.
chasil 2y ago
The deal killer for me, the inescapable aspect of my users, is that they insist upon checking passwords into revision control. Because the C and PL/SQL people are on CVS, I can fix this with vi on the ,v archive. First on TFS repositories, and now with git grep I can easily find exposed passwords for many things. But it's just SQL Server! We will never be able to use git responsibly, so I will peruse this guide with academic interest. Don't even get me started on secrecy management. I am looking forward to retirement!
- rblatz 2y ago
  The devs shouldn’t have access to prod credentials in the first place. That’s the real issue.
  - chasil 2y ago

20k 2y ago

Honestly, 99% of the pain of git is simply because people use it through the CLI. If you use tortoisegit or a visual tool, you don't need to worry about any of this because its self explanatory, and it becomes trivial to use Learning git like this is honestly just hampering yourself

wruza 2y ago
I’ve seen tortoise users break their repo, struggle to understand the issue and then push it through, making it everyone’s problem. Git language is screwed, you cannot unscrew it with a right-click gui because you basically click some latin-looking hieroglyphs that you don’t know either way.
- globular-toast 2y ago
  I highly doubt tortoise or any tool can "break" a repo. This might be a sign that you don't understand git either. Now I'm sure it can lead to people who don't know what they're doing doing the wrong thing, but if they're allowed to push somewhere and make it someone else's problem, that's not their fault. They've been forced to use git, so there should be someone else who actually understands git.
  - _puk 2y ago
    Ah, we're holding it wrong. Got it.
  - wruza 2y ago
    “Break” doesn’t mean repo integrity corruption. It means that you try to merge a branch, and it shits itself with hundreds of conflicts that shouldn’t appear and/or has changes that may partially revert the progress made by other merges. if they're allowed to push somewhere and make it someone else's problem, that's not their fault What? This made zeroest sense of the day. Like, I should walk to their desk and check if a feature branch is okay to push or what?
    - 2y ago

ggregoire 2y ago

I can make a 5 line HN comment explaining how to use git: 1. git clone 2. git checkout 3. git pull 4. git add + commit + push 5. git reset / rebase

juped 2y ago

Why are programmers so vehemently angry over the fact that a complex tool which does complex things to a complex data structure might have some complexity to it?

zanellato19 2y ago
"I don't understand this complexity so this means it shouldn't exist"
- keithalewis 2y ago
  Linus wrote it, so there's got to be a pony in there somewhere. He's the first person in the world to figure out version control software. /s
solidasparagus 2y ago
It's the de facto tool for our industry. For the vast majority of cases, users bear the burden of that complexity without gaining much benefit. And (at least for me) it doesn't guarantee the one thing I need it to do - make sure I can never lose progress.
andrewflnr 2y ago
The data structure isn't that complex. Most of the things we want to do to it aren't that complex. And yet... https://xkcd.com/1597 https://xkcd.com/1597