On Fri, May 12, 2023 at 03:06:25AM +0000, James Cook wrote:
> Here, no new commits were added to "main" since the previous vendor
> merge. But the tip of "main" is not an ancestor to the tip of "vendor"
> so there's nothing to worry about: the simpler heuristic (just the
> ancestor check) will do the right thing.
> 
> Conversely, we may want to fast-forward when the tip of the work tree
> branch is a merge. E.g. perhaps yesterday I merged "vendor" into "main",
> then today someone else pushed some changes on top of that. When I pull
> today's changes, there's no reason not to just fast-forward; the fact
> that yesterday ended with a merge commit is just a coincidence.

If we can indeed get by with a simpler heuristic than it definitely makes
sense to start out that way. If we run into issues we can always add
more tweaks on top.

> But maybe I'm missing something?

I suppose as long as a -M option is provided which allows users to override
our heuristic we are not going to break anyone's use case. Whatever their
rationale happens to be.