4 ms·

This (and the reply to js2) gives me the impression that "effectively use 5% of git" means something like "effectively use 5% of the git CLI surface", but to me

This (and the reply to js2) gives me the impression that "effectively use 5% of git" means something like "effectively use 5% of the git CLI surface", but to me that's not what "learn how to use git" means. One way or another, I've wound up becoming the git guy at work, and think I'm on the more proficient side of average. But, for most anything outside of commands I use daily (or can easily find in shell history), I'm off to the git docs or a search engine. Just about always, I know what I need git to do, it's just a matter of finding an incantation to do it. To me, there are two pieces to learning git. The lower level is about git itself: understanding that commits are snapshots and the diffs are calculated on-the-fly, that cherry-pick is an automated version of diff and patch, rebase is like a way to compose cherry-picks. The other layer is about how the organisation uses git - like how to fork a project on github, push some changes to a branch in your fork, make a PR to propose those changes to upstream, why committing directly to main is a bad idea.

Someone 4y ago
> understanding that commits are snapshots and the diffs are calculated on-the-fly I never understood why that gets mentioned as essential for understanding git. A version control system has to be able to produce both all versions of a given file and diffs between versions of a file, but how it does that is an implementation detail. There are many options there: full first version with diffs to newer versions, full last version with diffs to older versions, variants of those with full versions inserted every now and then, mixes of forward and backward diffs (as is done in some video formats, if you see each frame as a version of a file), etc. Of course, there may be performance reasons for choosing an implementation. I could understand statements such as “Because of the existence of merge commits, it’s easier to store full files, rather than diffs, as a merge commit would have diffs with each of its parent that must be kept consistent”, but the “understanding that commits are snapshots” claim isn’t about implantation details, but claimed to be essential to understand git.
- nicoburns 4y ago
  I think a key thing that may be trying to be communicated here is that in guy, commits are primitive, and not branches.
- bacon_waffle 4y ago
  That's a good question, and I don't have a straightforward answer. I think git sits in a sort of uncanny valley, where it's possible to go a long way treating the tool as a black box (and you're totally right - snapshots vs diffs is an implementation detail), but in practice, to really "get it" it's necessary to understand a bit about what is going on under the hood. The problem space that git addresses is inherently difficult, in contrast git internals are quite straightforward. So, a person wanting to learn git has two options: they can keep the hood closed, study the manual, and fret over all the complicated looking knobs and switches. Or, they can have a look under the hood, realise that there really isn't much to it. Most of those controls just aren't relevant to do what they need to do at the moment, and when a problem arises they have a much better idea of where to look for solutions. In my experience, being a well-rounded software engineer (for instance able to collaborate with a team at work, and make the occasional PR to random outside projects) requires a certain level of git proficiency. At that level of proficiency, the black-box approach seems to have a much steeper learning curve than the look-under-the-hood approach. At a less philosophical level: git is a collaboration tool, and people get hopelessly confused about this stuff when they try to collaborate without sharing a common language. "How do I email a commit?" is the sort of question I get asked occasionally.

Someone 4y ago

> understanding that commits are snapshots and the diffs are calculated on-the-fly I never understood why that gets mentioned as essential for understanding git. A version control system has to be able to produce both all versions of a given file and diffs between versions of a file, but how it does that is an implementation detail. There are many options there: full first version with diffs to newer versions, full last version with diffs to older versions, variants of those with full versions inserted every now and then, mixes of forward and backward diffs (as is done in some video formats, if you see each frame as a version of a file), etc. Of course, there may be performance reasons for choosing an implementation. I could understand statements such as “Because of the existence of merge commits, it’s easier to store full files, rather than diffs, as a merge commit would have diffs with each of its parent that must be kept consistent”, but the “understanding that commits are snapshots” claim isn’t about implantation details, but claimed to be essential to understand git.

nicoburns 4y ago
I think a key thing that may be trying to be communicated here is that in guy, commits are primitive, and not branches.
bacon_waffle 4y ago
That's a good question, and I don't have a straightforward answer. I think git sits in a sort of uncanny valley, where it's possible to go a long way treating the tool as a black box (and you're totally right - snapshots vs diffs is an implementation detail), but in practice, to really "get it" it's necessary to understand a bit about what is going on under the hood. The problem space that git addresses is inherently difficult, in contrast git internals are quite straightforward. So, a person wanting to learn git has two options: they can keep the hood closed, study the manual, and fret over all the complicated looking knobs and switches. Or, they can have a look under the hood, realise that there really isn't much to it. Most of those controls just aren't relevant to do what they need to do at the moment, and when a problem arises they have a much better idea of where to look for solutions. In my experience, being a well-rounded software engineer (for instance able to collaborate with a team at work, and make the occasional PR to random outside projects) requires a certain level of git proficiency. At that level of proficiency, the black-box approach seems to have a much steeper learning curve than the look-under-the-hood approach. At a less philosophical level: git is a collaboration tool, and people get hopelessly confused about this stuff when they try to collaborate without sharing a common language. "How do I email a commit?" is the sort of question I get asked occasionally.