* On 2013 27 Feb 04:32 -0600, Stefano Lattarini wrote: > It also stated: > > I also propose the following change to the branching scheme currently > implemented in the Automake Git repository: > > * The 'maint' branch will be reserved to cut of the next micro > release; so it will just see fixes for regressions, trivial > bugs, or documentation issues, and no "active" development > whatsoever. > > * The 'master' branch will be where the development of the next > minor release will take place; that is, a sort of "middle-ground" > between the roles so far fulfilled by the 'maint' and 'master' > branches in the current branching scheme. > > * The (new) 'next' branch will be reserved for the development > of the next major release; it will basically take over the rule > that is currently fulfilled by the 'master' branch. > > I thought that was making clear that the then-current 'maint' and > 'master' branches would have needed to be renamed in order to implement > that new scheme. But re-reading the above, I realize I wasn't making > that clear at all (it sounded clear to me because the details were > fresh and clear in my mind then).
As I just lurk looking for tips as I'm a downstream prjoct maintainer/developer, I did not pay much attention other than to know that version numbers would be changing in the future. Fine. As to the three bullet points above, those are sensible policies, IMO. I'll admit that I don't see the need for any renaming of branches, which I presumed was bad in Git land, but not being an experienced Git maintainer (only two years under my belt) I kept quiet, particularly since this isn't my project. :-) > Not in this case, as 'master' had several commits lacking in 'maint'. Would 'git cherry-pick' have worked? I've used it a lot between branches that have divereged to where I would not want a normal merge but for the patch in question cherry picking allowed me to update the other branch where the individual files had not diverged, if that makes sense. To track the history of the cherry-pick I used the '-x' option to give a link back to the commit it was 'picked from. > This would have obtained the wrong effect; what was in master before my > attempted renaming shouldn't have landed in the new 'master', but only > in 'next'. In the new 'master', we only wanted what was in the old 'maint'. In other words, master contained commits intended for '2.0'+ (for instance) that you didn't want in 1.13+, etc.? Perhaps a new branch for 1.13+ cut from some earlier commit in master and leaving master alone would have worked? 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. In the project I've inherited, I look at master as the development trunk and stable releases are branched off of it. In a stable branch any "point" releases are simply signed annotated tags and not a new branch. For my purposes a stable branch indcates new or improved hardware support and "point" release tags indicate bug fixes and nothing more. In fact I have one long running stable branch that is a year old that has received various fixes while master continues to track toward our next major release. Almost no cherry-picking is taking place between them now. Developers are free to create topic branches and merge them into master as they see fit. In fact I have one such branch where I added, at long last, Readline support to our testing utilities. I'll probably merge it into master and delete it this weekend. The good thing about Git is that it does not eforce such policy. The bad thing about Git is that it does not enforce such policy. ;-) - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us
