On 02/27/2013 02:07 PM, Nate Bargmann wrote: > > [SNIP] > >> Not in this case, as 'master' had several commits lacking in 'maint'. > > Would 'git cherry-pick' have worked? > No, because those commit were to be *dropped* (not added) from master; the old 'master' containing them was to be renamed to 'next'.
> [SNIP] > > In other words, master contained commits intended for '2.0'+ (for > instance) that you didn't want in 1.13+, etc.? > Exactly. > Perhaps a new branch for > 1.13+ cut from some earlier commit in master and leaving master alone > would have worked? > What would have worked with minimal disruption would have been to keep the current names until the next major version (maybe just renaming 'branch-1.13.2' to 'fix' or 'micro' *after* the bug-fixing release); just after the new major release, 'fix', 'maint' and 'master' would have pointed to the *same* commit, so we could have juggled and swapped their names without causing any non-ff push. I thought the disruption of doing the renames right now would have been negligible anyway, but apparently I was badly wrong in that. > master would have then been consigned to being for > new development which isn't what you explicitly stated in the policy > above. I have to agree with Miles on the common assumption of the > master branch in Git as sort of a quasi-stable of the development tree. > So we should maybe go (after the next major release) with this naming scheme for the branches? * maint -> for next micro version * stable -> for next minor version * master -> for next major version > [SNIP] Thank, Stefano
