On Fri, Jun 23, 2023 at 03:56:30PM +0000, James Cook wrote:
> I don't have a strong opinion here, but at the moment it seems tricky to
> edit a merge commit after it's created, which is a point in favour of
> making -n the default. (As an experiment, I just tried editing a merge
> commit with got histedit, and the second parent was lost.)

Good catch. I agree this histedit behaviour is less than ideal.
 
> Fossil's merge command doesn't create the commit, probably because
> probably because it's near-impossible to undo a commit in fossil. Maybe
> if got histedit is fixed this reason doesn't apply.

One doesn't preclude the other. Histedit can be fixed independently
of whether merge defaults to -n behaviour.

If you think -n is a better default then I'd be happy with that change.

> > We could have 'got merge' open an editor with the default message
> > in the buffer. The cherrypick and backout commands do this, too.
> 
> This sounds useful. Custom messages like "update libfoo to 3.7" or
> "merge libfoo update" are probably more useful to see in the log than
> generic "merge refs/heads/libfoo into refs/heads/main", especially if
> the log is restricted to linear history (which seems like a sensible
> default).
> 
> Here's todo list for merges. (A couple of others are in the TODO file.)
> My time is a unpredictable but I may work on some of these within the
> next few weeks, if others don't take them.
> 
> - Make "got merge" refuse to change refs outside of refs/heads
> - Add got merge -M option.
> - Allow editing / specifying the commit message.
> - Fix histedit so it's hard to accidentally turn a merge commit into a
>   linear commit. (Maybe it should just refuse to traverse merge commits
>   for now.)

Makes sense to me. (As you noted in a follow-up, the refs/heads issue is
already fixed.)