Stefan Sperling <stsp@stsp.name> 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.