Re: Bad translation merge

[David Kastrup]

Francisco Vila <address@hidden> writes:

> 2012/3/7 David Kastrup <address@hidden>:
>>
>> Hi, the recent translation merge apparently made some wrong choices when
>> dealing with merge conflicts.  Changes in staging have been overwritten
>> in the following files:
>>
>> Documentation/snippets/centering-markup-on-note-heads-automatically.ly
>> Documentation/snippets/defining-an-engraver-in-scheme-ambitus-engraver.ly
>> Documentation/snippets/numbers-as-easy-note-heads.ly
>> GNUmakefile.in
>> input/regression/autobeam-3-4-rules.ly
>> input/regression/multiple-time-sig-settings.ly
>> lily/book-scheme.cc
>> lily/parser.yy
>>
>> and a whole lot of others.
>
> Sorry for coming lately, I'm at work. This is what I know:
>
> I do not merge lilypond/translation into master. I do merge master
> into lilypond/translation and lilypond/translation into staging.

Yes, I figured that this was not likely to be the cause of our problem.

> I rebased by mistake (instead of merging) lilypond/translation into
> staging and my reasoning was: provided that staging does 'make && make
> doc' and it has all the new work from translations, staging is not
> damaged in any way, for now. Translations are not damaged in any way,
> either.

The problem here is that the commits in "translations" are considered to
be independent from the commits introducing the same changed in
"staging".  That's bad for a variety of reasons.  For example, if you
revert one of the two commits in one branch and then merge a branch with
the non-reverted cousin, that cousin is brought in again instead of
being considered reverted.

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.

If you try clever things, then at least check using git diff with the
parents that they did what you think they did.

> That's what I did and worked fine apparently.

How did you check?

> All work is there,

Not according to git diff.  The result of the "merge" is identical to
_one_ of the parents.

> everything compiles well.

Well, it would.  The work tree was identical to something that compiled
previously.

> Today, I merged translations into staging and some conflicts arose,
> but they were trivial, with the '====<<<translations' part being
> empty, so it was clear to me that I should always choose the part with
> new content, namely the '>>>HEAD' part. That's what I manually did
> today. Only four or five files were affected.

Files that were _not_ part of the Documentation tree.  If you get
conflicts in files and directories you did not work on in the
translation branch, something is wrong.

> Then I checked 'make && make doc' while in staging, with the merge
> conflicts resolved and commited. Everything looked fine, so I pushed.
>
> What did I do wrongly? (apart from the superfluous rebase)

The rebase _is_ creating trouble when we have to revert things.  It also
makes it harder for merge resolution to work.

But the thing that _really_ messed up the translation branch was the
merge with strategy "theirs" or "ours".  You need to check the results
of "clever" merges with git diff against its parents.  That stuff
compiles is _no_ guarantee that a merge happened.  In fact, the only way
to have compiling fail given two branches that compiled on their own is
_when_ an actual merge happened.  So compiling/testing is not helpful
for checking the integrity of a merge.  Only for checking the integrity
of the result.

You have to use git diff (and git diff --stat) against the parents to
check a merge for plausability.

Yes, it is an ungrateful job as translation master: other people can
work for years without ever having to push a merge commit.

-- 
David Kastrup