[petsc-dev] PTScotch 6

[Satish Balay]

On Tue, 19 Mar 2013, Jed Brown wrote:

> 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.

So if the branch is quick-fix-merge-to-master - then its ok not to
create a remote 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.

Hm - so 'if branch from maint - eventual merge destination for branch/patch is maint'?

> 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
> 

But this increates the probability of merge conflicts that would have
to be manually resolved. And we've avoided doing this before. So now
we do these extra 'manual' merges now?

Satish