5 ms·

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 explaini

by 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
    Internal audit said the same thing. Quelle surprise!
  - sampullman 2y ago
    Commiting credentials is also a real issue, best to avoid doing both.
  - zelphirkalt 2y ago
    Then you need to hire someone else to manage the deployment of services though.
- rswail 2y ago
  Sounds like you need a pre-commit hook to check.
  - maccard 2y ago
    Pre commit hooks aren’t enforcable. People need to opt in to them, and the people who opt in to them are the people who will check for passwords before they commit.
    - n_plus_1_acc 2y ago
      Server-side pre-recieve hooks are better
billdueber 2y ago
Sigh. Another git thread, another pile of posts telling me that if I would _just do the work_ to understand the underlying data structure I could finally allow myself to be swept up in the _overwhelming beauty_ of the something something something. The evidence that the git UI is awful is _overwhelming_. Yes, yes, I’m sure the people that defend it are very very very very smart, and don’t own a TV, and only listen to albums of Halloween sounds from the 1950s and are happy to type the word “shrug“ and go on to tell us how they’ve always found git transparent and easy. The fact is that brilliant people struggle with git every single day, and would almost certainly be better served by something that makes more sense.
- Izkata 2y ago
  GP isn't describing the underlying data structures, they're describing the basic interface of commits, branches, and tags. The 101 stuff you have to learn regardless, for any version control, not just git. Dismissing it like this just sounds like someone who refuses to hold scissors by the handles.
  - billdueber 2y ago
    You’re right, of course, and I apologize to GP for conflating what they were saying with what I, to be fair, do often see in these threads. Like others in these comments, I can use it just fine right up until I can’t. Then it’s back to the mini, many, many posts and questions and tutorials, sprawled across the Internet to try and solve whatever the issue is. JJ has shown that a better chrome can be put over the underlying model, And it’s frustrating to me that we are all collectively, apparently, expected to put up with a tool that generates so much confusion seemingly regardless of brilliance or expertise
- ajross 2y ago
  Pretty much, yeah. Just do the work. It's not nearly as hard as whatever it is you're committing into it, I promise. Continuing to mock it via florid metaphor doesn't help anyone at this point.
  - 2y ago
rtpg 2y ago
I think the trickiness with the simple abstraction is that you end up looking at a commit graph and thinking "I would like to make a couple new nodes in this in a very specific shape, but one that many people have likely done in the past. Is there a trick?" Like so much of the porcelain is those kinds of tricks, and make otherwise tedious work much simpler. Imagine if you didn't have interactive rebases! You could trudge through the work that is done in interactive rebases by hand, but there's stuff to help you with that specific workflow, because it is both complicated yet common. I think jujutsu is a great layer over git precisely because you end up with much simpler answers to "how do I change up the commit graph", though.... the extra complication of splitting up changes from commits ends up making other stuff simpler IMO. But I still really appreciate git.
wruza 2y ago
This doesn’t work. Look: Commits are sets of files. They form a tree. A branch is a named location in this tree. The index aka staging area is a pre-commit that has no message. Workdir is just workdir, it doesn’t go in the repo unless you stage it. HEAD is whereafter commit will put new changes. Do I understand git? Seems like yes. Let’s run a quiz then! Q? A. How to make a branch? Git branch -a? Git checkout -b --new? Idk. How to switch to a branch? Git switch <name>, but not sure what happens to a non-clean workdir. Better make a copy, probably. Also make sure the branch was fetched, or you may create a local branch with the same name. How to revert a file in a workdir to HEAD? Oh, I know that, git restore <path>! Earlier it was something git reset -hard, but dangerous wrt workdir if you miss a filename, so you just download it from git{hub,lab} and replace it in a workdir. How to revert a file to what was staged? No idea. How to return to a few commits back? Hmmm… git checkout <hash>, but then HEAD gets detached, I guess. So you can’t just commit further, you have to… idfk, honestly. Probably move main branch “pointer” to there, no idea how. If you have b:main with some file and b:br1 with it, and b:br2 with it, and git doesn’t store patches, only files, then when you change b:main/file, then change and merge+resolve b:br1/file, then merge that into b:br2 to make it up-to-date, will these changes, when merged back to already changed b:main become conflicted? Iow, where does git keep track of 3-way diff base for back-and-forth reactualization merges? How does rebase know that? Does it? I have no idea. Better make a copy and /usr/bin/diff [—ignore-pattern] the trees afterwards to make sure the changes were correct. As demonstrated, knowing the base abstractions doesn’t make you know how to do things in git. I don’t even disagree, just wanted to say fuck git, I guess. Read guides or not, google or reason, you’re screwed either way.
- abenga 2y ago
  Skill issue, it seems. Facetiousness aside, the things you do often, you learn once and you don't really have to remember/think when doing them. Most of the esoteric operations are mostly unnecessary to burden yourself with until you actually have to do them, when you just read the documentation.
- ajross 2y ago
  Literally every one of those questions can be trivially googled. (In previous generations and fora, this is where you'd be mocked with LMGTFY links). You just, to continue to embrace the frame, don't want to do the work. If you insist on memorizing commands for all these tasks (of which there are many), indeed, you're going to struggle and decide you need a 30 section guide. But you don't, and want to whine about it. > I don’t even disagree, just wanted to say fuck git, I guess. Pretty much.
ssivark 2y ago
> 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. This is about as useful as "A monad is just a monoid in the category of endofunctors." It's basically a lot of words which make zero sense for a user starting to use git -- even if it happens to be the most succinct explanation once they've understood git. > 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. You can't really learn the former -- you can't even see it till you've experienced it for a while. The typical user groks what it means after that experience. Correction, actually: the typical user simply gives up in abject frustration. The user who survived many months of using a tool they don't understand might finally be enlightened about the elegant conceptual model of git.
globular-toast 2y ago
There is one fundamental piece missing in your description of git that I think is the main reason people don't understand it. You have described a single DAG, but in git there are multiple DAGs. This is what it means to be a distributed version control system. In my experience people come to git and start using it with the centralised paradigm in their heads: that there is one repo and one DAG etc. They think that their master branch is the same as "the" master branch. You just can't get good at git with this wrong understanding.
- HdS84 2y ago
  My problem is that I always use git as a central server. Except that one time when our internal git was down and we used it peer to peer for a day. Honestly, using USB sticks for that would also have been okay.
  - globular-toast 2y ago
    > Honestly, using USB sticks for that would also have been okay. Right! People often forget git was designed specifically for Linux kernel development which is done by a loosely-knit global base of developers. There are much simpler solutions if you can actually live with exchanging USB sticks. One nice thing is only needing to know one tool for both open source and centralised development, though. It can seem a little odd if you don't do any open source at all, though.

by ajross 2y ago

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
  Internal audit said the same thing. Quelle surprise!
- sampullman 2y ago
  Commiting credentials is also a real issue, best to avoid doing both.
- zelphirkalt 2y ago
  Then you need to hire someone else to manage the deployment of services though.
rswail 2y ago
Sounds like you need a pre-commit hook to check.
- maccard 2y ago
  Pre commit hooks aren’t enforcable. People need to opt in to them, and the people who opt in to them are the people who will check for passwords before they commit.
  - n_plus_1_acc 2y ago
    Server-side pre-recieve hooks are better

billdueber 2y ago

Sigh. Another git thread, another pile of posts telling me that if I would _just do the work_ to understand the underlying data structure I could finally allow myself to be swept up in the _overwhelming beauty_ of the something something something. The evidence that the git UI is awful is _overwhelming_. Yes, yes, I’m sure the people that defend it are very very very very smart, and don’t own a TV, and only listen to albums of Halloween sounds from the 1950s and are happy to type the word “shrug“ and go on to tell us how they’ve always found git transparent and easy. The fact is that brilliant people struggle with git every single day, and would almost certainly be better served by something that makes more sense.

Izkata 2y ago
GP isn't describing the underlying data structures, they're describing the basic interface of commits, branches, and tags. The 101 stuff you have to learn regardless, for any version control, not just git. Dismissing it like this just sounds like someone who refuses to hold scissors by the handles.
- billdueber 2y ago
  You’re right, of course, and I apologize to GP for conflating what they were saying with what I, to be fair, do often see in these threads. Like others in these comments, I can use it just fine right up until I can’t. Then it’s back to the mini, many, many posts and questions and tutorials, sprawled across the Internet to try and solve whatever the issue is. JJ has shown that a better chrome can be put over the underlying model, And it’s frustrating to me that we are all collectively, apparently, expected to put up with a tool that generates so much confusion seemingly regardless of brilliance or expertise
ajross 2y ago
Pretty much, yeah. Just do the work. It's not nearly as hard as whatever it is you're committing into it, I promise. Continuing to mock it via florid metaphor doesn't help anyone at this point.
- 2y ago

rtpg 2y ago

I think the trickiness with the simple abstraction is that you end up looking at a commit graph and thinking "I would like to make a couple new nodes in this in a very specific shape, but one that many people have likely done in the past. Is there a trick?" Like so much of the porcelain is those kinds of tricks, and make otherwise tedious work much simpler. Imagine if you didn't have interactive rebases! You could trudge through the work that is done in interactive rebases by hand, but there's stuff to help you with that specific workflow, because it is both complicated yet common. I think jujutsu is a great layer over git precisely because you end up with much simpler answers to "how do I change up the commit graph", though.... the extra complication of splitting up changes from commits ends up making other stuff simpler IMO. But I still really appreciate git.

wruza 2y ago

This doesn’t work. Look: Commits are sets of files. They form a tree. A branch is a named location in this tree. The index aka staging area is a pre-commit that has no message. Workdir is just workdir, it doesn’t go in the repo unless you stage it. HEAD is whereafter commit will put new changes. Do I understand git? Seems like yes. Let’s run a quiz then! Q? A. How to make a branch? Git branch -a? Git checkout -b --new? Idk. How to switch to a branch? Git switch <name>, but not sure what happens to a non-clean workdir. Better make a copy, probably. Also make sure the branch was fetched, or you may create a local branch with the same name. How to revert a file in a workdir to HEAD? Oh, I know that, git restore <path>! Earlier it was something git reset -hard, but dangerous wrt workdir if you miss a filename, so you just download it from git{hub,lab} and replace it in a workdir. How to revert a file to what was staged? No idea. How to return to a few commits back? Hmmm… git checkout <hash>, but then HEAD gets detached, I guess. So you can’t just commit further, you have to… idfk, honestly. Probably move main branch “pointer” to there, no idea how. If you have b:main with some file and b:br1 with it, and b:br2 with it, and git doesn’t store patches, only files, then when you change b:main/file, then change and merge+resolve b:br1/file, then merge that into b:br2 to make it up-to-date, will these changes, when merged back to already changed b:main become conflicted? Iow, where does git keep track of 3-way diff base for back-and-forth reactualization merges? How does rebase know that? Does it? I have no idea. Better make a copy and /usr/bin/diff [—ignore-pattern] the trees afterwards to make sure the changes were correct. As demonstrated, knowing the base abstractions doesn’t make you know how to do things in git. I don’t even disagree, just wanted to say fuck git, I guess. Read guides or not, google or reason, you’re screwed either way.

abenga 2y ago
Skill issue, it seems. Facetiousness aside, the things you do often, you learn once and you don't really have to remember/think when doing them. Most of the esoteric operations are mostly unnecessary to burden yourself with until you actually have to do them, when you just read the documentation.
ajross 2y ago
Literally every one of those questions can be trivially googled. (In previous generations and fora, this is where you'd be mocked with LMGTFY links). You just, to continue to embrace the frame, don't want to do the work. If you insist on memorizing commands for all these tasks (of which there are many), indeed, you're going to struggle and decide you need a 30 section guide. But you don't, and want to whine about it. > I don’t even disagree, just wanted to say fuck git, I guess. Pretty much.

ssivark 2y ago

> 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. This is about as useful as "A monad is just a monoid in the category of endofunctors." It's basically a lot of words which make zero sense for a user starting to use git -- even if it happens to be the most succinct explanation once they've understood git. > 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. You can't really learn the former -- you can't even see it till you've experienced it for a while. The typical user groks what it means after that experience. Correction, actually: the typical user simply gives up in abject frustration. The user who survived many months of using a tool they don't understand might finally be enlightened about the elegant conceptual model of git.

globular-toast 2y ago

There is one fundamental piece missing in your description of git that I think is the main reason people don't understand it. You have described a single DAG, but in git there are multiple DAGs. This is what it means to be a distributed version control system. In my experience people come to git and start using it with the centralised paradigm in their heads: that there is one repo and one DAG etc. They think that their master branch is the same as "the" master branch. You just can't get good at git with this wrong understanding.

HdS84 2y ago
My problem is that I always use git as a central server. Except that one time when our internal git was down and we used it peer to peer for a day. Honestly, using USB sticks for that would also have been okay.
- globular-toast 2y ago
  > Honestly, using USB sticks for that would also have been okay. Right! People often forget git was designed specifically for Linux kernel development which is done by a loosely-knit global base of developers. There are much simpler solutions if you can actually live with exchanging USB sticks. One nice thing is only needing to know one tool for both open source and centralised development, though. It can seem a little odd if you don't do any open source at all, though.