From: James Cook <falsifian@falsifian.org>
Subject: fast-forwarding
To: gameoftrees@openbsd.org
Date: Thu, 11 May 2023 04:54:39 +0000

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

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

-- 
James