3 ms·
Describing a git branch as a named sequence of commits implies that it's a specific sequence of commits. But without a merge base, a branch is an ambiguous seq
by xn 4y ago
Describing a git branch as a named sequence of commits implies that it's a specific sequence of commits. But without a merge base, a branch is an ambiguous sequence of commits.
Ergo, a git branch is a named sequence of commits [when the implied merge base is obvious].
- smusamashah 4y agoI dont understand what author is trying to say. I always understood branch as just a pointer on a linked list of commits. You can freely move around this pointer. Head is similarly another pointer to the current commit. This plus each commit is contains whole file which was changed in that commit. Is author saying the same thing or is he saying that each commit also has some hard-coded reference to the branch in it too?
- Karellen 4y agoI'm struggling to follow why a merge base makes a difference? Or even exactly what one is? A couple of questions which might help clear things up: Do you consider `main` a branch? If you create a new branch called `feature1`, do you consider the commits from before the branch from `main` to be "part of" that branch or not? What if you delete `main`? Are the commits from before the branch part of the `feature1` branch then? What if there are multiple surviving feature branches that share varying amounts of common history?
- xn 4y agomain is a branch. By convention, it contains all of the commits back to an ancestor that has no parents. Unless given more information, I would consider the commits between `git merge-base main feature1` (exclusive) and feature1 (inclusive) as part of the feature1 branch. Now, if I `git checkout -b feature1-A feature1`, what commits are part of branch feature1-A? It depends. With respect to which merge base?