Re: [PATCH v6] doc: add an explanation of Git's data model
- From
Chris Torek <chris.torek@gmail.com>
- Date
- Nov 13, 2025, 20:34 UTC
- Message-ID
- <CAPx1Gvcf5=nBg9=AakfF=2tXVakBfddt7vTj+Wy9-497OcjviQ@mail.gmail.com>
- In-Reply-To
- <160ef4a8-8e9c-4034-9607-2f268fdbf29d@app.fastmail.com>
On Thu, Nov 13, 2025 at 12:19 PM Julia Evans <julia@jvns.ca> wrote:
Show 8 quoted lines
> To immediately contradict myself a bit: after sending this I thought to > look through Mark Dominus's great blog posts about Git to see if > he has anything to say about this, and I came across this article: > https://blog.plover.com/prog/git/branches.html, called "I wish people > would stop insisting that Git branches are nothing but refs". > > It reminded me that of course in Git the word "branch" often is used > to mean "a sequence of commits" ...
Yes, this is the crux of the issue: The word "branch" is ambiguous.
In Git, the *branch name* is the `refs/heads/whatever` name, and we also have remote-tracking branch names under `refs/remotes/`. The *branch*, however, is some ill-defined set of commits starting from the specific commit identified by a branch name *or* any other unique identifier, and then working backwards for some unspecified number of steps with unspecified constraints.
Sometimes the bare term "branch" means one or another of these various things, and sometimes it's meant to encompass all of them...
Chris