[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

git branch strategy after 1.11

From: Ralf Wildenhues
Subject: git branch strategy after 1.11
Date: Sun, 22 Mar 2009 12:23:35 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hello everyone,

just to let you know, after 1.11 I intend to change the branch setup a
bit.  When branch-1-11 is created, I will also create a branch maint,
which will then receive bug fixes appropriate for both 1.11.x and 1.11a.
The maint branch will then be merged regularly (most likely after every
commit or set of commits) into both branch-1-11 and master.

Once branch-1-12 branches off of master, maint will be fast-forwarded
to the branch point.  I tried this out to verify for myself that this
will be a fast-forward: since maint is completely merged in master,
master is a direct descendant of maint.

See attached picture for what I mean.  Although this should explain it
better, I guess: <>.

An alternative naming strategy would be maint-1-11.  That way it would
be simpler to add bugfixes to branch-1-10 even after the maintenance
branch has moved to the branch-1-12 branch point.  OTOH, if we want to
fix things in old branches, we can always open up a new oldmaint or
maint-X-Y branch then.

Comments appreciated.  The general goal is that, branches branch-1-10
and older excluded, there should not ever be duplicate patches in the
public tree (i.e., cherry-picked from one branch to another).  This will
probably mean there will be more small non-public branches which will
end up merged in public ones.  Thanks Jan for hinting me toward this.

Anyway, the test release for 1.11 will come from the 'next' branch, and
will have master, je-silent, and ad-parallel-tests merged into it.


Attachment: merge.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]