[petsc-dev] PTScotch 6

[Jed Brown]

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>