From: James Cook <falsifian@falsifian.org>
Subject: Re: why got merge creates a commit immediately?
To: Omar Polo <op@omarpolo.com>, gameoftrees@openbsd.org
Date: Fri, 23 Jun 2023 15:56:30 +0000

On Sun, Jun 18, 2023 at 10:16:22PM +0200, Stefan Sperling wrote:
> 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.

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.)

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.

> >  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.

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.)

-- 
James