Re: git branch strategy after 1.11

[Jan Engelhardt]

Hi Ralf,

On Tuesday 2009-03-24 22:48, Ralf Wildenhues wrote:
>
>> And: once branch-1.11 development finally ceases, it can be deleted.
>> This works because the commits remain reachable via the release tags.
>> If necessary, the branch pointer can simply be recreated.
>
>What would be the advantage of deleting a release branch?

Maybe, first, to clarify, doing this deletion is only meaningful
when the branch pointer would coincide with a tag. Otherwise you
would lose commits if the bp deviated from what is reachable from
the tag, of course.

Hm, less refs to download for the user. Not that those 40 bytes matter ;-)
Seriously, I really thought "whoops" when I was swamped by the lot of
branches in
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=heads
when I downloaded it once to cherrypick some commits.

>What I had in mind was keeping the release branches as we do now,
>and pushing the occasional bugfix there that distributors are likely
>to pick up, rather than each roll their own, slightly incompatible one.

Nothing to say against that in itself.

>OTOH, with temporary feature branches like je-silent or ad-parallel-tests
>it seems useful to delete them sometime after they have been completely
>merged into master, and we don't expect further bug fixes in the area.

And if there does happen to be a fix to that specific branch
(hypothethically; realisitically we'd just slap it onto master),
you just recreate the branch at the last commit, apply the patch,
push out the branch. Since it is a fast-forward for users who
still have the branch pointer with its old value, there are no
unexpected interruptions.


Jan