On Wed, Jan 31, 2024 at 05:37:20PM +0100, Christian Weisgerber wrote:
> Landry Breuil:
> 
> > i never 'rename' branches, but:
> 
> I see.  I have a hard time wrapping my head around merge-based
> commit flows.
> 
> > - during the beta cycle, commits happen in the beta branch
> > - if there's a 0.1 release, i commit it in the master branch, then merge
> >   master branch into beta branch (fixing conflicts in Makefile and distinfo)
> 
> And those are the only merge actions that create actual merge
> commits ("Merge branch 'master' into beta").
> 
> > - at RC time, beta branch is merged to release branch
> > - at release time:
> >   - i commit everything to cvs from the release branch,
> >   - then commit the CVS churn changes to the release branch,
> >   - then merge the release branch to master branch,
> >   - then merge the master branch to beta branch,
> >   - then start working on the next beta1 version
> 
> All of those merges are actually done by fast forwarding one branch
> to the tip of the other branch.
> 
> Let's say I originally checked out a work tree when "master" was
> at revision 9cd4661.  Then I run "git fetch", and now I have this
> commit graph for "origin/master" for the Firefox 122 release cycle
> (git log --graph --oneline):
> 
> * e551c3f (origin/release, origin/master, release) 122.0 pushed to cvs
> * e4bbeb3 122.0rc2 is final
> * 6233288 122.0rc2
> * a4f95ba bump SO_VERSION
> * cd92017 122.0rc1
> * 6e2ecb0 122.0b9
> * 4bb3030 fetch repacked profdata
> * 5adf0d5 122.0b8
> *   de0fe38 Merge branch 'master' into beta
> |\  
> | * 9cd4661 (HEAD -> master) 121.0.1 pushed to cvs
> | * 1adb933 drop patches from #1863135 & #1871006, merged upstream
> | * 4e6975f 121.0.1
> * | db348b2 122.0b6
> * | efcbd3f 122.0b5
> * | d4f7b03 drop patches merged upstream
> * | faf066f 122.0b4
> * | a1a9c53 122.0b3
> * | 39cc0c5 122.0b2
> * | 595e7cf upstream switched to llvm 17 so we need to repack the profdata again ..
> * | 265f3fe cvs churn after dropping patch
> * | eac21bd drop patch from #1868782, merged upstream
> * | fc52bf7 122.0b1
> |/  
> * 1782bfb 121.0 pushed to cvs
> 
> With got(1), how do I catch up "master" to "origin/master"?
> 
> That merge commit de0fe38 prevents rebasing "master" on "origin/master".

Does "master" above mean commit 9cd4661 (HEAD -> master)?

got rebase only does a first-parent traversal.
I suppose Git's rebase command is smarter than this.

Got then merges the entire difference between 1782bfb and 9cd4661
into a worktree of e551c3f in one step, and all changes between
fc52bf7 and 9cd4661 get applied to files where those changes are
already present, causing merge conflicts.

> Merging "origin/master" into "master" works.  That's hard to predict
> or analyze with got(1), though.

I think using 'got merge' is the best answer, for now.
It should do the fast-forwarding you expected 'got rebase' to do.

Perhaps rebasing across merge commits should be prevented outright,
even if that would prevent some workflows?