Re: Bad translation merge

[David Kastrup]

David Kastrup <address@hidden> writes:

> Don't rebase either origin and translation.  Simple rule.  Don't try
> being clever about it: being clever around git is a recipe for disaster.
> If you messed up your own repository (and that does not mean "merely"
> the state of the work tree, but the history of commits), don't push.
> Ask.  We will figure out how to get it back into a nice state.
>
>> Then I waited until patchy merges into master, so I can now be sure
>> that all those commits are 'upstream'. I could now safely merge master
>> into translations as usual. When I will eventually merge again,
>> duplicate commits should ideally combine in a single history.
>>
>> If not, and if we have any conflicts, I could merge with strategy
>> recursive and option 'theirs'.
>
> Well, there we are.  It would appear that you used the merge strategy
> "theirs" rather than "recursive + option theirs".  The respective merge
> _claims_ to merge two commits but doesn't.  It just takes the tree from
> "theirs" unchanged.  At least this is what happened with the merge I
> traced to be faulty.

Ok, I take that back: this merge might not necessarily be the exact
cause of the trouble.  If you merge an original branch again after you
already rebased it, the merge conflict resolution would essentially
resolve to what the rebased branch already had.  So that merge
resolution would indeed look like a one-sided merge strategy in its
outcome.

Digging further.

-- 
David Kastrup