I like branches. But I don't like YOUR branchesI don't like git's branches. But then again, I don't really like Mercurial's branches. Or Bazaar's branches. Or Perforce/SVN/CVS/RCS branches. I may be polluted: I used CVS branches extensively, back in the day. Heck, I used RCS branches in RCS-wrapper-tools. I've used Mercurial and Bazaar branche extensively. I like what Brad Appleton has written about branches in
Streamed Lines: Branching Patterns for Parallel Software Development - but then again, Brad and friends are really talked about streams of software development, not branches. This may really be the problem: several different concepts use the same underlying mechanism.
This post is work in progress. I want to make some notes about branches, often in reaction to statements in other webpages. I will try to properly reference those webpages - but I am more interested in evolving the ideas than being properly academic.
Why I am writing this
Similarly, I may not have noticed features added during git's evolution.
2) I am intrigued by analogies between version control software and OOO speculative hardware. Git, in particular, is all about rewriting history to be "nice". OOO speculation is similarly about making execution appear to be in a serializable order. Similarly, memory ordering hardware often performs operations in an order inconsistent with the architectural memory ordering model, but monitors and/or repairs to be consistent.
Random Note Snippings
---+ Branch Names and Versions
[Contreras 2011] In Mercurial, a branch is embedded in a commit; a commit done in the ‘do-test’ branch will always remain in such a branch. This means you cannot delete, or rename branches, because you would be changing the history of the commits on those branches.
(Yeah: Mercurial's obsession with immutable history tends to get in the way of clear thinking. But HGers (huggers?) rewrite history all the time, eg via rebase. So imagine that we are talking about a hypothetical VCS that wants to keep some of the good things about CVS and HG and BZR style branches.)
Wait! We are talking about version control systems!!! VCSes are all about uniqifying different objects with the same name! For that matter, so are hierarchical directory structures. And so on, e.g. object labels and tags.
==> How to distinguish different branch objects with same name.
==> Encourage actions that helpm distinguish branches.
E.g. instead of saying "switch to branch BBB", where BBB is created if it does not already exists,
Prefer "create new branch BBB" which may warn you if name BBB already exists.
==> PROBLEM: tools that might simply go "merge branchname" might now have to say "branchname is not unique - which instance of branchname do you want to merge?" Yet another error case, but not necessarily a real error, just an ambiguity.
How do we resolve such ambiguities?
b) priority - eg. PATH for hierarchical. Choose the branch that is "closest" to the guy doing the merge.
---+ Contours? Who needs Contours?
---+ SVN / Perforce Style branches
VCSes are all about uniqifying different objects with the same name! For that matter, so are hierarchical directory structures.SVN and Perforce subsume the former in the latter: branches are really just trees in the hierarchical directory structure.
...Pros/cons. Workspaces assembled from multiple branches. Where does the branch level live? "Floating"
---+ Git Branch Descriptions are not first class
---+ [StackOverflow 2009]
A single git repository can track an arbitrary number of branches, but your working tree (if you have any) is associated with just one of them (the "current" or "checked out" branch).
GLEW COMMENT: I have often wanted to create working trees which are composed of several branches. Yeah, yeah - you can simulate this by merges - but I want to make it convenient.
E.g. say that a particular configuration = mainline of most code, but the FOO branch of some library libFoo. Yes, this is almost equivalent to saying that the this configuration is really all the FOO branch - but it provides more information, in saying that "Yes, the configuration is FOO specific, but in general we expect only the libFoo library to be different with FOO."
My thoughts on partial checkins and checkouts often involve this. More, partial repositories. Referencing tools and repos that have separate version ciontrol systems. libXXX may be checked into its own repo in isolation as that repo's mainline. But from the point of view of some other tool that uses XXX, say T,, libXXX's mainline is not T's mainline. Yet(?). A partial checkin of libXXX amounts to creating a CANDIDATE for T's mainline. Once the candidate is tested, it becomes T's mainline, assuming tests pass. But if tests fail, T's version of libXXX may lag, or may fork and diverge from libXXX's mainline.
This notion of "candidate" maps well to Git's model. Such a candidate is just a HEAD. Once tested, the candidate label may go away, and no longer clutter our listings of branches and tags and other named references.
---+ [Contreras 2011] and [Contreras 2012]
[Contreras 2011] and [Contreras 2012] provided good comparisons of the Git and Mercurial branching mechanisms,. But Contreras is fairly rabid about git, and makes many statements of the form "Which would anyone ever need to do it in that way? There's a different way to do it in git. Or, you should not need to do it - I never have." That sort of statement pisses me off, even when I agree with it.
[Contreras 2011] Reacting to Google’s analysis comparing Hg with Git, that says that History is Sacred.
This was an invalid argument from the beginning. Whether history is sacred or not depends on the project, many Git projects have such policy, and they don’t allow rebases of already published branches. You don’t need your SCM to be designed specifically to disallow your developers to do something (in fact rebases are also possible in Mercurial); this should be handled as a policy. If you really want to prevent your developers from doing this, it’s easy to do that with a Git hook. So really, Mercurial doesn’t have any advantage here.
(1) I agree: it MUST be possible to change history.
(1.1) Or at least to be able to remove some things from the history, e.g. it must be possible to remove code that you do not have a license for, that was inappropriately checked into your repo. Or possibly code that you HAD a license for at some point in time, but for which the license expired.
I would prefer it if the code with license problems was removed, but some sort of note left behind. Possibly an automated note, e.g. with a crypto checksum/hash and other metadata, sio that you could determine what the missing code should be if you ever again have a license.
But I can also imagine the need to hide one's tracks: to completely expunged all mention of the unlicensed code. Trying to avoid lawsuits.
(1.2) Plus, I like the good history rewriting stuff like rebase.
(1.2') Even better if we can change our view of the history, without losing the history
BUT... I really would prefer that rebase did not lose history. I think that it can sometimes be useful to know that a branch started off with a different original base, and was rebased later. If nothing else, it can explain bugs caused by the rebased code using an idiom that was otherwise eliminated between original base and the new rebase's origin. I think of this as an original branch, and a rebase'd shadow of that original branch.
Yes, clutter: But I think that we need to create a UI that hides such clutter, that presents only the clean history, but which remembers all the dirty details.
[Contreras 2011] It’s all in the branches ... Say I have a colleague called Bob, and he is working on a new feature, and create a temporary branch called ‘do-test’, I want to merge his changes to my master branch, however, the branch is so simple that I would prefer it to be hidden from the history.
GLEW COMMENT: so hide it already. Hide = leave in the history, but don't show it by default. As opposed to removing it from the history.
Some articles and references[StackOverflow 2009] := StackOverflow: Pros and Cons of Different Branching Models in DVCS
[Brad 1998] := Streamed Lines: Branching Patterns for Parallel Software Development TBD notes
[Contreras 2011] := Mercurial vs Git - It's All in the Branches. Nice overview, although Git biased.
[Contreras 2012] := No, mercurial branches are still not better than git ones; response to jhw’s More On Mercurial vs. Git (with Graphs!)
[StackOverflow 2015 - add Git branch name to commit message]
[Stackoverflow 2009 Jakub] := Git and Mercurial – Compare and Contrast - much liked by [Contreras 2011] TBD - notes
TBD: J. H. Woodyatt’s blog post