merge conflict tedium

merge conflict tedium

[Glenn Morris]

Hi,

I have set up automatic merging of the emacs-26 branch to master some
time ago. I feel like I quite often have to intervene due to needless
merge conflicts that can't be resolved automatically but could have been
avoided with a little effort.

Today's problems were caused by:
1) 08840f2
Unlabelled backport of a year old commit from master?
Adding an explicit "backport" or "cherry-pick" message to the commit would
have avoided this.

2) 536e6de and 13b586d, and b513feb
Conceptually the same commit (?), but made on different branches without
any indication, coupled with a simultaneous reformat on master. Changing
the same code on multiple branches at the same time is a PITA. Please
merge it yourself if doing that.

End of complaint! :)

Re: merge conflict tedium

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> Hi,

Hi Glenn,

> Today's problems were caused by:
> 1) 08840f2
> 2) 536e6de and 13b586d, and b513feb

All of these commits are mine, and I'm very sorry for that. It happens
again and again that I forget the "don't merge" idiom in the commit
message, and even if I recognize it after the commit (it happens), I
don't know how to add it after a push. Is there something I could do?

> Conceptually the same commit (?), but made on different branches without
> any indication, coupled with a simultaneous reformat on master. Changing
> the same code on multiple branches at the same time is a PITA. Please
> merge it yourself if doing that.

It is not intended to be merged. After the crewation of Emacs 26.1.91,
I've seen on emba, that the code I've resolved in the morning in the
master branch, needed to be adapted also in the emacs-26 branch. A
cherry pick wasn't possible, so the looks-like-identical merge. Again, I
forgot to say "don't merge".

Do we have any other mean, to handle such situations? The current
workflow requires to add the proper wording during commit. I cannot
promise this will always work, so some more robust approach would be
welcome.

> End of complaint! :)

You have all rights to complain! I'm very sorry about.

Best regards, Michael.

Re: merge conflict tedium

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Glenn,

> Do we have any other mean, to handle such situations? The current
> workflow requires to add the proper wording during commit. I cannot
> promise this will always work, so some more robust approach would be
> welcome.

Maybe it is possible, to ask in the *release-branch*, whether this
shall be merged to master. Interactively, when committing. This sole
question would be sufficient, at least for me.

Best regards, Michael.

Re: merge conflict tedium

[Paul Eggert]

On 1/7/19 12:59 PM, Michael Albinus wrote:
> It happens
> again and again that I forget the "don't merge" idiom in the commit
> message, and even if I recognize it after the commit (it happens), I
> don't know how to add it after a push. Is there something I could do?

I've made that mistake myself, and the simplest fix I thought of was to 
immediately merge the emacs-26 branch myself to master, making sure that 
I handle the mistake correctly during the merge.

If you don't know how to do such a merge, now's a good time to learn....

Re: merge conflict tedium

[Glenn Morris]

Paul Eggert wrote:

> I've made that mistake myself, and the simplest fix I thought of was
> to immediately merge the emacs-26 branch myself to master, making sure
> that I handle the mistake correctly during the merge.

I think that's the best solution.

None of this is a big deal! :)

Re: merge conflict tedium

[Glenn Morris]

Michael Albinus wrote:

> Maybe it is possible, to ask in the *release-branch*, whether this
> shall be merged to master. Interactively, when committing. This sole
> question would be sufficient, at least for me.

Maybe that is a check you could implement locally for your use, but I
really wouldn't worry about it.

Re: merge conflict tedium

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> Michael Albinus wrote:
>
>> Maybe it is possible, to ask in the *release-branch*, whether this
>> shall be merged to master. Interactively, when committing. This sole
>> question would be sufficient, at least for me.
>
> Maybe that is a check you could implement locally for your use, but I
> really wouldn't worry about it.

I've ended up in a private function for `vc-before-checkin-hook'.

Best regards, Michael.