Luke Diamand <luke@xxxxxxxxxxx> writes: > 2. Merge > ... > If I do "git merge bugfix" onto relbranch, then as well as getting X, > I also get B and C, which I don't want. This won't work exactly for the reason why you want to do #3 below. > 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. > ... > 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? Just to throw another in for completeness (not claiming which one is better and which one is worse): 5. Primarily use #3 to merge, but use "cherry-pick -x" when replaying a fix that was built on a wrong base, and tweak the procedure to find out "is this fix already on branch X?" to also pay attention to it. It is no worse than #4, I would think, as both approaches would need to scan the commit log messages to find the commits that are not in the ancestry chain that participated to the branch.
