On Thu, May 11, 2023 at 04:54:39AM +0000, James Cook wrote:
> Hi list,
> 
> I brought something similar up on IRC on Feb 24; maybe it's good to have
> this on the list.
> 
> Consider this commit graph where the branch "feature" is ahead of main:
> 
> o  <- feature
> |\
> o o  <- main
> |/
> o
> 
> As far as I can tell, got doesn't support a simple way to "fast-forward"
> main to point to feature in this situation.
> 
> got integrate fails with:
> 	got: specified branch must be rebased first
> Am I correct to assume this is working as intended? (In a similar
> context it was explained on IRC that 'got integrate' is intended for a
> particular use case not general fast-forwards.)
> 
> A similar situation where I've wanted to use "got integrate" in the
> past:
> 
> o  <- origin/main
> |
> o  <- main
> 
> In both cases I'd love the ability to simply fast-forward in one
> command.
> 
> Two ideas came up on IRC at the time:
> 
> - 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?

>   I don't know if got wants to
>   support creating this kind of merge commit, and if so, whether it
>   should be the default or fast-forwarding should be the default.)

I believe Got should try to prefer linear history over merge commits
by default because this makes the history easier to browse. I'd rather
upset people who want to craft a more complicated outcome and know what
they are doing, than upsetting people who don't want to deal with more
complicated braching/merging patterns and want the tool to "just work".
So if 'got merge' without any options did the right thing for users who
prefer linear history when possible than that would be fine with me.

> - Add a "got fastforward -b other" command which updates the current
>   branch to point to "other", as long as "other" is a successor to the
>   current branch.
>
> Either one would also be useful to me.

I would prefer this being added to 'got merge' rather than adding a
new command. 'got rebase' already fast-forwards when possible. The fact
that 'got merge' does not this yet is a mistake. I simply forgot to
consider this case when 'got merge' was added as a new command to
provide the ability to create merge commits. At the time I didn't
realize that fast-forwarding with 'got merge' would be useful after
fetching branches from remote repositories. And by the way, I also
forgot about this when 'got rebase' was initially added. Fast-forwarding
was added later when someone (kn@ I think?) pointed out to me that it
was missing.

'got merge' could offer a command line option and/or environment variable
and/or config knob to prevent fast-forwarding for situations where users
want to avoid it. But it should fast-forward by default whenever possible,
at least until we figure out a good reason for why it should not do this.

Thanks to histedit users can always go back and redo the merge if they
don't like the default merge result, and if they care deeply enough they
will remember to pass the no-fast-forward flag next time (or just use Git).

> I don't know which which be more consistent with got's philosophy (or if
> neither is) but if there's enthusiasm for either one, I could try
> implementing it. (Might be a little while before I have time.)

Thanks, that would be great!