Re: Manual merges.

[Peter Rosin]

Hi Stefano,

Stefano Lattarini skrev 2011-10-21 10:17:
> On Friday 21 October 2011, Peter Rosin wrote:
>> Hi!
>>
> Hi Peter.
> 
>> I checked to see what would happen if I merged maint back into msvc after
>> commiting the AM_PROG_AR series, and there is some minor testsuite fallout
>> that needs to be fixed manually.  My plan was to amend the merge commit
>> with the fixups, along with a note in ChangeLog pointing to what files
>> I'm touching etc.  The question is how I should label the resulting commit.
>>
>> The merges normally get commit messages like
>>
>>> Merge branch 'maint' into msvc
>>
>> but that does not look like a normal ChangeLog header. But that's the best
>> I can think of.
>>
>> So, a commit message along these lines:
>>
>>> Merge branch 'maint' into msvc
>>>
>>> * tests/foo.test: Adjust to new portability requirements due
>>> to the new AM_PROG_AR macro.
>>> * tests/bar.test: Likewise.
>>
>> And this in ChangeLog:
>>
>>> 4711-17-42  Peter Rosin  <address@hidden>
>>>
>>>     Merge branch 'maint' into msvc
>>>     * tests/foo.test: Adjust to new portability requirements due
>>>     to the new AM_PROG_AR macro.
>>>     * tests/bar.test: Likewise.
>>
>> Sounds like a plan?
>>
> Yes.  But I can also see two other possibilities:
> 
>  - Fix the failing tests in a follow-up patch; this way, you can write
>    a "usual" commit message and a "usual" ChangeLog entry.

But then you get failing tests for one commit. Could be a nuisance for
someone later doing a bisect.  Other projects "forbid" that, and I'm
quite understanding of that position.

>  - Amend the merge commit, but instead of adding a new ChangeLog entry,
>    edit the one(s) from the commits you are merging (while keeping the
>    commit message of the merge as in your example).

Yes, in this case however, that edit in the ChangeLog would be a nop
since the original entry has a blanket "All relevant tests: ..."
covering the needed changes. So, the change would be "silent" according
to the ChangeLog.  At least if the ChangeLog is badly ordered, which it
tend to be, and resorting to sorting (argh, no pun intended) it manually
seems like a massive tool failure.

If you actually do have a ChangeLog entry that can be edited to also list
the new fixup, it would look very strange if that entry ends up before
the entry which added a new file that needed fixup in the merge. Especially
if the new file was added in a change newer than the change causing the
new file to need fixup in the merge. Unless you doctor the date on the
ChangeLog causing the fixup to be needed, but doing that is just plain
evil.

Should I perhaps file a bug that the ChangeLog file should be generated?

> I'm not sure which of these three options (the one proposed by you
> and the one proposed by me) would be preferable, and I must say I have
> no real preference either.  So you choose (unless Someone Else wants
> to chime in and override my advice ;-)

I think my suggestion is the only one without drawbacks for the general
case when manual merges are required.

Cheers,
Peter