On Fri, Jun 30, 2023 at 10:37:34PM +0000, James Cook wrote:
> The below patch adds an -M option to got merge which makes it create a
> merge commit even if fast-forwarding is possible. (The merge can still
> be interrupted by a conflict or the -n option.)
> 
> Notes:
> 
> - Is M the right letter for this option? I think the answer is "yes" but
>   this is sort of the last chance to change our minds.

Your diff is OK by me.

I agree -M is fine. And it is not yet the last chance to make a change.
Until we explicitly decide to freeze the UI at some point in the future
we can still change anything, any time.
It is much too early for granting such guarantees to users. I would guess
a first point of no return would be crossed if/when OpenBSD starts relying
on Got for production, at which point we should consider setting the
version number to 1.0. But even then, we should not be afraid to reconsider
past decisions and fix mistakes. We'd just have to be a bit more careful by
allowing users to smoothly transition across breaking changes somehow.

>   Devil's advocate: if we decide to make -n the default, it's possible
>   we'd want to make "-M" might the opposite of -n, i.e. create the merge
>   commit without interrupting. (But there are plenty of other letters.
>   It's too bad -C ("commit!") is already used. Maybe "-c" could serve
>   two purposes, continuing and opposite of -n; not sure if that's a good
>   idea.)

We could just flip the meaning of -n around and document it diferently.
 
> - Option conflicts for "got merge" could use work. "c" + "n" isn't
>   detected, and the man page is wrong that "no other command-line
>   arguments are allowed" with "-c", since "-C" is permitted.

Indeed. Please feel free to adjust things if you spot simple mistakes
like this. Thanks!