Necessity mother of invention

Necessity mother of invention

I think there's some confusion over terminology going on here.

In particular around "deleting branches". My understanding is that in git this is removing the branch pointer. But this is a confusing concept in general to those of us who cut our teeth on "history is immutable" DVCSs.

Whilst the equivalences you point out are true, I would suggest that names are very important. To suggest a daft strawman, they're as important as variable names. For one thing, integration with bug tracking systems: we have all sorts of hooks which look at the branch name and pass commit comments into the relevant bug in bugzilla (this is much nicer than adding specific tags to commit comments which are easy to forget to do).

Also, if the bug (and by bug I mean bug/feature/story/whatever/unit-of-work) gets reopened even after merging, it still makes sense to want to group all these commits together even if there ends up being multiple merges from bug-branch to master/trunk/stable/ready-for-qa/whatever. In even more extreme cases, you could actually need multiple branches of the same name - say if I have a "dev" and "stable" branch and I'm told to implement feature X documented in bug18723, I might well create a branch off "dev" called "bug18723" which implements it one way, but it turns out that so much has changed in the mean time and that management says we must backport this feature, that I create an entirely separate branch off "stable" also called "bug18723". Now these two branches are entirely unrelated in terms of the DAG of changesets, but they conceptually relate to the same feature and so should have the same name. It's basically impossible to deal with this situation in git (yes, you could do a lot of reset --hard bug18723 and track the commit shas manually, but this is basically equivalent to working without named branches, which as you point out, could be done).

What you need to be able to deal with this sort of issue is for a branch to not be a pointer to a single changeset, but an arbitrary set of changesets.

There's another example where greater flexibility with branches is a good idea. Say that someone has wrongly merged a branch to default. You want to back that out but unfortunately there are now downstream changesets already. You might think to commit a revert, but the problem there is that due to die-die-die, when the branch eventually gets merged correctly, the revert will likely win and you'll have to tidy up all the pieces yourself. So a better idea is to go back to the changeset on master before the erroneous merge, and fork from there but on master. So:

master: A -> B -> C -> D -> ...
         \       /
branch:   X -> Y

C is the bad merge. We now make some arbitrary (normally whitespace) change to B, creating a C', which is still on master:

                C'
               /
master: A -> B -> C -> D -> ...
         \       /
branch:   X -> Y

And we now merge the descendants of C into our "junk" branch:

                C'
               /
master: A -> B -> C -> D -> ...
         \       /              \
branch:   X -> Y                 \
                        \    \    \
junk:                    J -> K -> L

and then reapply those changesets onto C':

                C'-> D'-> ...
               /
master: A -> B -> C -> D -> ...
         \       /              \
branch:   X -> Y                 \
                        \    \    \
junk:                    J -> K -> L

Now we can continue to develop our branch as a child of Y, we have master at some descendant of D', we have no erroneous dangling branches, and we've never had to commit a revert, so die-die-die won't bite us.

Whilst all of this is possible in git, because it can't do a branch with multiple heads (and here, at many points we have master with multiple heads), it makes it much more painful than it ought to be.

I think your later points really get back to the idea that local can differ from remote. If you have integration with bug trackers and so forth, it really doesn't make sense to name your local branches differently from your remote branches, and I would suggest that it is the minority case where this level of flexibility is an important feature. Consequently, if you do have unified branch names and integration with other tooling, branch names are both long lived and frequently very important. IME, the way kernel dev is done is the exception rather than the norm. Now I'm not so daft as to suggest the kernel development process is being done "wrongly" at all - quite the opposite - and git is clearly a tool that fits the requirements there well. However, and this is quite possibly just my own biased opinion, it seems to me that it's incorrect to assume that all projects would "do better" if they used the same toolset as the kernel. Obviously, no one is forcing me to use git (well, actually, some projects at work are), but the popularity of github and the prevailing monoculture is a touch alarming.