How to recover after criss-cross merge?

[Manuel Jacob]

On 2016-01-13 22:24, Matt Mackall wrote:
> On Wed, 2016-01-13 at 22:06 +0100, Manuel Jacob wrote:
>> Hi,
>> 
>> In the PyPy repository [1] we have three branches (which are 
>> interesting
>> for this post): "default", "py3k", "py3.3".  "py3k" branched from
>> "default" and we regularly merge "default" into "py3k".  "py3.3"
>> branched from "py3k" and we regularly merge "py3k" into "py3.3".
>> 
>> Everything worked fine until someone merged directly from "default" to
>> "py3.3" (changeset 4fa19970ddeb), skipping "py3k".  When merging from
>> "py3k" into "py3.3" the next time (changeset 88aafcb7c318) we ran into
>> problems.  It showed many "ambiguous merge - picked m action" 
>> warnings.
> 
> That's fine.
> 
>> Also, some files (e.g. lib-python/3/_abcoll.py) which were removed in
>> the "py3.3" branch (but still existent in "py3k") re-appeared without
>> warning.
> 
> But that's more of a problem. Bid merge currently doesn't attempt to 
> resolve the
> ambiguity between deleted in one merge and modified in another.

Could it be changed to at least report a warning in this case?

>> I'd prefer to only redo all changes from just before the merge from
>> "py3k" into "py3.3".  I tested (locally) redoing this merge (changeset
>> 88aafcb7c318) with aeafe30eac60 as a merge base (by passing "--config
>> merge.preferancestor=aeafe30eac60").  This changeset aeafe30eac60 is 
>> the
>> last commit from "py3k" which got merged into "py3.3" before
>> 88aafcb7c318.  It seems to do exactly what I want.  However the next
>> time I merged "py3k" into "py3.3" (after in turn merging "default" 
>> into
>> "py3k") I ran into problems again (ambiguous merge warnings and
>> re-appearing files).  Is there a way to permanently fix the problem?
> 
> You can declare "everyone out of the pool", clean things up, do a 
> proper set of
> merges, and then restart work. So long as there are more recent common 
> ancestors
> to choose for future "correct" merges

Is this possible without rebasing everything since the "criss-crossing" 
merge from default to py3.3?

> and no one tries to merge on their pre-
> event branches, it should work.

I'm not sure what you mean.  We still want to merge from default into 
py3k and from py3k into py3.3.