From: Christian Weisgerber <naddy@mips.inka.de>
Subject: Re: Landry's firefox repository
To: Landry Breuil <landry@openbsd.org>
Cc: gameoftrees@openbsd.org
Date: Wed, 31 Jan 2024 17:37:20 +0100

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".
Merging "origin/master" into "master" works.  That's hard to predict
or analyze with got(1), though.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de