On Thu, May 11, 2023 at 08:00:21AM +0200, Stefan Sperling wrote:
> On Thu, May 11, 2023 at 04:54:39AM +0000, James Cook wrote:
> > - Make "got merge" fast-forward when possible. (Possible conflict: some
> >   users may want the ability to explicitly create a merge commit even
> >   when they could have fast-forwarded. E.g. I've seen this recommended
> >   when merging pull requests: then the commit graph clearly
> >   distinguishes between the proposed change and the act of merging it
> >   into the main branch; this would be lost if main were simply fast
> >   forwarded to the pull request's commit.
> 
> Is there ever any non-cosmetic reason to pefer merge commits over
> fast-forwarding?

Turns out there is an item in the TODO file which lists details from
prior discussions we've had. This shows why some amount of heuristics
will be needed:

- Teach 'got merge' to forward a branch reference if possible, instead of
  creating a merge commit. Forwarding should only be done if linear
  history exists from the tip of the branch being merged to the tip of
  the work tree's branch, and if the tip of the work tree's branch is
  itself not a merge commit (this makes "stacked" merges possible
  by default, and prevents a 'main' branch reference from being forwarded
  to a vendor branch in case no new commits were added to 'main' since
  the previous vendor merge). Provide an option (-M) which forces creation
  of a merge commit, for cases where users deem forwarding undesirable.

If all this makes sense to you then let's run with these ideas for now.
We might run into other edge cases later but we can deal with those
when we get there.

I do trust your judgement on the details of this use case since you
are using this command much more than I do.