From: Stefan Sperling Subject: Re: fast-forwarding To: James Cook Cc: gameoftrees@openbsd.org Date: Thu, 11 May 2023 08:00:21 +0200 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!