[petsc-dev] PETSc developers who use weird MPI

[Satish Balay]

On Fri, 1 Nov 2013, Jed Brown wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
> 
> > On Fri, 1 Nov 2013, Satish Balay wrote:
> >
> >> >    The reason I had to merge all that stuff into saws was that saws
> >> >    could not merge into next because those branches so changed
> >> >    next. I had to merge them into saws before I could get saws into
> >> >    next.
> 
> Peter forgot what had been released to 'next' and rebased after merging,
> leading to two copies of the earlier commits.  I think that is the
> reason for much of this confusion.
> 
> >> >    But I missed 1/2 a one (somehow) getting an outdated verson of
> >> >    the sf-sfbasics into saws.
> >> > 
> >> 
> >> No the more appropriate thing here would be to merge/rebase to latest
> >> master.
> >> 
> >> And then attempt to merge saws to next.
> >
> > $ git log --oneline
> > f3d19ed fix outdated PetscOptionsList
> > d548240 Merge branch 'prbrune/mat-matcolor' into barry/saws
> > 3142415 Fix for multiple definitions in mat/color/interface/ custom fortran bindings
> > 76422c6 manually remove old AMS code that got sucked in from master
> > fcaff9f Merge branch 'jed/check-pointer-runtime' into barry/saws
> > 1a1c1e0 partial update of SAWs with master
> > 7737a22 Merge branch 'master' into barry/saws
> >
> > I see you have merged master into barry/saws
> 
> Why this merge "from upstream"?
> 
> > - and then had to merge jed/check-pointer-runtime and
> > prbrune/mat-matcolor
> >
> > I'm not sure what can be done here. [my instinct is to reset 'saws' to
> > either 7737a22 or the state before that - and redo the 'merge to
> > master', and then 'rebase -i' the other required commits - or just
> > rebase master onto barry/saws].
> 
> I haven't followed the sequence of events (in transit to airport, now
> boarded).  What has gone wrong now?
> 
> Whatever you do, please don't rebase 'barry/saws' now, since it has been
> merged to 'next'.

[I'm not doing this but ...]
Me thinks it should be ok to rebase after merge to next. i.e 

- on next - revert previous merge of branch-x
- on branch rebase [-i or eqivalent]
- merge branch to next

Sure - we should avoid this on master..

Satish