3 ms·
> each commit points to their parent. Therefore, you don't need to track the entire sequence of commits in the branch but just the commit at the tip. This is n
by pdonis 4y ago
> each commit points to their parent. Therefore, you don't need to track the entire sequence of commits in the branch but just the commit at the tip.
This is not entirely true, because it is perfectly possible to create commit graphs in git in which there is not a single well-defined branch for some commits. So just knowing the branch labels at each tip is not sufficient to assign a single well-defined branch to every commit in the graph.
Mercurial branches don't work like this: they are actually stored as part of each commit, so even with ambiguous commit graphs each commit still has a well-defined branch.
- TacticalCoder 4y agoYeah I much preferred Mercurial from that standpoint. And branches there were correctly named branch. But you kinda, sorta, can get "what should have been called branches but don't exist in Git" by using named tags when you "start a branch" (a real branch I mean, not a Git "branch"). > Mercurial branches don't work like this: they are actually stored as part of each commit, so even with ambiguous commit graphs each commit still has a well-defined branch. I wonder which operation would not be possible with Git had Git gone that way. And hence I wonder too what's that operation that Git can do and that Mercurial can't. Honestly switching from Mercurial to Git this weird "branch that aren't branch at all" was the single most WTF feature of Git.