On Tue, Mar 19, 2013 at 11:56 AM, Satish Balay <balay at mcs.anl.gov> wrote:
> A couple of follow-on questions for this. > > Should one create remote branches for all such branches? > Yes, at least if you want to provide information to others about the branches. If you are going to be responsible for all merging and maintenance, then I guess you could merge without pushing the branch. We can find strays around release time using $ git log --no-merges master..next but those won't show up in $ comm -12 <(git branch -r --no-merged master) <(git branch -r --merged next) | grep -v next > How does one keep track of the 'merge path' the branch is destined to? > One kows this before the branch is create and then remembers it until > it gets merged to all its destinations? [or use some complicated git > commands to keep track of this?] > We can always look at the ancestor of the branch to see where it started from. Note that it's fine to make a branch starting at 'maint', but never bother to merge it back to 'maint'. If at some later time, anyone wants to make another maintenance release, they can merge it at that time. Here is an example. When Junio fixed the bug, he did it in a topic branch based off a very old maintenance branch that the patches were never actually merged into. Now someone who wants to backport gets it in a single merge. http://permalink.gmane.org/gmane.comp.version-control.git/214870 $ git log --graph --oneline v1.7.6.6..4682d85 * 4682d85 diff-index.c: "git diff" has no need to read blob from the standard input * 3b069b1 diff-index.c: unify handling of command line paths * c20f592 diff-index.c: do not pretend paths are pathspecs -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130319/c18595ac/attachment.html>
