Re: Bad translation merge

[David Kastrup]

David Kastrup <address@hidden> writes:

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

man git-rebase has a few interesting bits:

        -m, --merge
            Use merging strategies to rebase. When the recursive
            (default) merge strategy is used, this allows rebase to
            be aware of renames on the upstream side.

            Note that a rebase merge works by replaying each commit
            from the working branch on top of the <upstream>
            branch. Because of this, when a merge conflict happens,
            the side reported as ours is the so-far rebased series,
            starting with <upstream>, and theirs is the working
            branch. In other words, the sides are swapped.

Also

        -p, --preserve-merges
            Instead of ignoring merges, try to recreate them.

            This uses the --interactive machinery internally, but
            combining it with the --interactive option explicitly is
            generally not a good idea unless you know what you are
            doing (see BUGS below).


Merge commits are usually _ignored_ when rebasing.  This includes merges
from master into translation.  If you rebased the translation branch on
an _old_ version of master (namely on your local master rather than
origin/master).  Hm, no, I still don't get what happened.  I need to
figure out more.

-- 
David Kastrup