From: "Omar Polo" Subject: Re: (test&doc only) RFC: allow editing merge commit messages To: Stefan Sperling Cc: James Cook , gameoftrees@openbsd.org Date: Sun, 08 Nov 2026 12:55:15 +0100 Stefan Sperling wrote: > On Sun, Nov 08, 2026 at 02:19:47AM +0000, James Cook wrote: > > I am very particular about my merge commit messages.* The below > > patch adds documentation and regress for a -e option to got merge, > > which would open an editor for the merge commit message. > > > > (It also adds the existing -M flag to got's usage message. > > > > Two questions: > > > > 1. Is this feature wanted? > > Yes, I don't see a reason not to have this. > > > 2. How about having it as the default? That would be my own preference; > > I never want the message got auto-generates. > > I would be fine with having the editor open up by default, always, > without even adding a new command line flag. > Like it is done during histedit -c after histedit -e, for example. +1, i was wondering why got merge behaves like this. > Always offering the possibilty to edit is better than requiring users > who would like to edit their message to roll everything back and try > again with -e. > > Some commands such as 'got commit' check whether the temporary file > storing the log message was modified before proceeding. In case of > 'got merge' it would need to proceed anyway, even if the auto-generated > log message was not modified by the editor. However, perhaps empty log > messages should be caught and rejected with a retry-loop, just in case. let's avoid an automatic retry-loop, or you won't be able to escape without committing the merge. `got mg -c' could then be used eventually to resurrect. > Regression tests would need to use tricks similar to those used > by the histedit tests where a shell script is used as $EDITOR.