Track changes across multiple branches, c.f. "p4 interchanges" ?
- From
Luke Diamand <luke@diamand.org>
- Date
- Apr 21, 2021, 09:54 UTC
- Message-ID
- <d9022ce8-2752-db75-f4b7-d5188c41bd90@diamand.org>
We're moving over from Perforce to git.
In Perforce we can find out definitively if a given commit is on branchA but not on branchB.
It doesn't use textual comparisons (c.f. "git change-id") but tracks which changes are on which branches.
This is invaluable for managing rapidly evolving sets of release branches.
How do I go about doing this in git?
1. Cherry
"git cherry" - but surely once the change gets sufficiently mangled by conflicts, won't it end up being "lost" ? That has certainly been my experience in the past.
2. Merge
I could work on feature branches, and then "git merge --no-ff" the feature branch - but when I do that I end up pulling all the intervening history over. e.g.
- X - bugfix
/ \
A - B - C - D - E - M main
\
R relbranchIf I do "git merge bugfix" onto relbranch, then as well as getting X, I also get B and C, which I don't want.
3. Always start from a merge base
I could tell people that if they are making a bugfix that will need to go onto multiple branches, that they need to start from some common merge base, and then merge to the final target branches.
That's possible, but is quite a big change from the current workflow of working on main and then "p4 integrate" individual changes over.
And invariably people will start out thinking their change is not a bugfix, but a new feature, and then find that actually we need the new feature on the release branch.
4. Use gerrit change-ids
We could adopt gerrit change-ids. It feels like this is kind of a kludge, but perhaps it's the only thing that really works?
Is there something better?
Thanks! Luke