3 ms·

It seems to me that "a branch is just a ref" is important knowledge to anyone developing git software or any other software that interacts directly with the fil

It seems to me that "a branch is just a ref" is important knowledge to anyone developing git software or any other software that interacts directly with the files in a git repo. For pretty much every other developer who's just using git for source control, "a branch is a named sequence of commits" is a much more useful way to understand them. I don't want to think about the implementation details of how git internally represents a branch any more than I want to think about whatever's going on inside a word .doc when I add a table into my document. The important thing is my branch (or table) works the way I and everybody else expects it to work. (It's good to have at least one person on your team who understands both those concepts deeply, as the obligatory xkcd explained...)

OJFord 4y ago
What's the distinction between '[interacting] with the files in a git repo' and 'just using git for source control'? To be clear I didn't say a branch isn't a named sequence of commits! I said it's a named ref to what is already a sequence of commits. I think people should understand their tools - not the internals/implementation detail (necessarily), just how to use them effectively. Today I had some post-incident reverting to do, and it was complicated by hairy merges, poor commit messages ('what' not why/the context), poor commit stucture & history, etc. And I'm sick of CI pipelines called 'Merge branch master of <remote url>' on the master branch (from doing merge-pulls of origin/master having committed to master locally - `git config pull.rebase true` if you're going to do that) - tells you absolutely nothing about the change that's actually building (because it's parent 1, not the commit itself or the merged parent 2) and causes a snaking history on master (flipping parents 1 & 2 every time someone does it). It's like a builder/'handiman' using a combi-drill day in day out in drill mode, using it for masonry & screws too, but not caring to realise the hammer & driver modes exist.

OJFord 4y ago

What's the distinction between '[interacting] with the files in a git repo' and 'just using git for source control'? To be clear I didn't say a branch isn't a named sequence of commits! I said it's a named ref to what is already a sequence of commits. I think people should understand their tools - not the internals/implementation detail (necessarily), just how to use them effectively. Today I had some post-incident reverting to do, and it was complicated by hairy merges, poor commit messages ('what' not why/the context), poor commit stucture & history, etc. And I'm sick of CI pipelines called 'Merge branch master of <remote url>' on the master branch (from doing merge-pulls of origin/master having committed to master locally - `git config pull.rebase true` if you're going to do that) - tells you absolutely nothing about the change that's actually building (because it's parent 1, not the commit itself or the merged parent 2) and causes a snaking history on master (flipping parents 1 & 2 every time someone does it). It's like a builder/'handiman' using a combi-drill day in day out in drill mode, using it for masonry & screws too, but not caring to realise the hammer & driver modes exist.