On Sun, Jun 18, 2023 at 09:00:40PM +0200, Omar Polo wrote:
> I usually prefer a linear history so I've never used 'got merge' until
> last week.  I also wasn't a user of 'git merge' before, so please
> apologize if these comments sounds naive.
> 
> There are two things that suprised me when I ran 'got merge branch':
> 
>  1. it immediately creates a commit; needs -n to avoid so.
> 
>     I've started to appreciate more and more how got backout or got
>     cherrypick don't create commits by default.  Being able to inspect
>     the changes on the worktree (not that I don't trust diff3 ;-) and
>     running tests and whatnot before committing is invaluable.

Rebase also creates a commit immediately. Merge can be viewed as the
same type of operation except that it feeds diff3 in a slightly different
way and never creates commits with more than one parent.

When I added 'got merge' I wanted to provide a way to create merge commits
instead of rebasing. Howver, I don't use 'got merge' myself and James in
particular has been finding gaps in functionality while actually using it.

>  2. i can't change the message.  the default is fine, but maybe
>     including an excerpt of the commits being merged (I know, it's not
>     exactly what happens since it merges trees, but still) or anyway
>     leaving up to me to tweak the message would be nice.

We could have 'got merge' open an editor with the default message
in the buffer. The cherrypick and backout commands do this, too.

> I'm not proposing any diff as I'd like to know how much of this is by
> design and how much still open for changes.
 
I suspect that 'got merge' would rarely be of use in an OpenBSD project
workflow. The only use case I can think of would be vendor branch merges.

It won't hurt to make 'got merge' behave in ways that are appealing to
users who are familiar with projects that run 'git merge' commands a lot
and/or who want to run 'got merge' a lot. Any changes proposed by people
who actually use the merge commands should be considered. Some things
'git merge' allows people to do go beyond what I would want to make
available and support (such as octopus merges with more than 2 parents).
So there are some red lines I'd rather not cross. But within those lines
we are flexible.