[petsc-dev] PETSc developers who use weird MPI

[Jed Brown]

Satish Balay <balay at mcs.anl.gov> writes:

> But spliting up the merge as 'merge sf-sfbasics to barry/saws' and then
> 'merge barry/saws to next' should be avoided.

It depends on what kind of conflicts arise.  It's easier and
topologically-cleaner history to just resolve conflicts in the eventual
merge (to 'next'/'master'), but if that is untenable, especially if it
requires functional changes in your branch (as opposed to syntactic),
then merging in their branch is sensible.

> BTW: in the normal workflow - a similar merge would be needed when
> 'barry/saws' gets merged to 'master' - but I think form what Jed said
> - git tracks this merge resolution in next - and reuses that for
> future merges [aka merge into master] - so that step should be
> seamless?

Git has a mechanism called REuse REcorded REsolution (rerere).  It is
off by default, but you can turn it on globally with

  git config --global rerere.enabled true

This is a set-and-forget option, and using it involves no special
commands.  When you commit a merge, the conflicted and resolved state is
cached privately.  If you later try to merge and get the same conflicts
(possibly going to different branches), Git will auto-resolve using the
recorded resolution.  It still marks the files as dirty so you have to
"approve" the resolution (git add).  It's good to build and run relevant
tests if there is any doubt that the resolution is correct, but that's
the same as any merge.


https://www.kernel.org/pub/software/scm/git/docs/git-rerere.html
http://gitster.livejournal.com/41795.html
http://stackoverflow.com/questions/3072155/git-workflow-throwaway-merges-and-git-rerere-whats-the-point
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131102/e386dc43/attachment.sig>