20 ms·

I think you can be technically accurate ('branch is a named ref') and still have the same mental model of branches described. A commit, specifically its ref, i

by OJFord 4y ago

I think you can be technically accurate ('branch is a named ref') and still have the same mental model of branches described. A commit, specifically its ref, is already encoding the 'sequence of commits' that led to it - viz. it knows its parent(s). A branch is a named pointer to one of those then, and 'nothing more', but that is already a sequence a commits.

Oxidation 4y ago
> and 'nothing more' Also it "follows along" when you commit to the branch. Named pointers that stay put are tags.
- OJFord 4y ago
  Good point, that is a bit of a quirk to the model. (Bloody useful, wouldn't have it another way obviously. But it is a special treatment more than 'a name for a commit'.) I suppose I can recover by saying 'committing creates a new commit, with HEAD as parent, and updates the checked out pointer to point at it'. Where no branch, a 'detached HEAD', is perhaps more thr special case - it's a sort of nameless transparent pointer that updates but you're only aware of the commit ref itself. Although again tag is also a special case in that it doesn't update, as you say. Really they're just all different ways of referring to a commit, doesn't really make sense to call any one of them the true way and the others special cases. I stand by the commit being the 'sequence of commits' though. So tldr, branches, tags, detached heads are just different mechanisms for referring to such a sequence: named and updates, named and static, unnamed/transparent. But in each case, they point to a commit, and inherently the sequence behind it.
bigiain 4y ago
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.

by OJFord 4y ago

Oxidation 4y ago

> and 'nothing more' Also it "follows along" when you commit to the branch. Named pointers that stay put are tags.

OJFord 4y ago
Good point, that is a bit of a quirk to the model. (Bloody useful, wouldn't have it another way obviously. But it is a special treatment more than 'a name for a commit'.) I suppose I can recover by saying 'committing creates a new commit, with HEAD as parent, and updates the checked out pointer to point at it'. Where no branch, a 'detached HEAD', is perhaps more thr special case - it's a sort of nameless transparent pointer that updates but you're only aware of the commit ref itself. Although again tag is also a special case in that it doesn't update, as you say. Really they're just all different ways of referring to a commit, doesn't really make sense to call any one of them the true way and the others special cases. I stand by the commit being the 'sequence of commits' though. So tldr, branches, tags, detached heads are just different mechanisms for referring to such a sequence: named and updates, named and static, unnamed/transparent. But in each case, they point to a commit, and inherently the sequence behind it.

bigiain 4y ago

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.