On 21.06.24 18:34, Junio C Hamano wrote: > Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > >> I can see why people want to revert merges but cherry-picking them >> always feels strange to me - what is the advantage over actually >> merging the branch and seeing the full history of that commit? > > One case that comes to my mind is when you failed to plan ahead and > used a wrong base when building a series to "fix" an old bug. You > built a 7-patch series to fix a bug that you introduced in release > 1.0, but instead of basing the fix on maint-1.0 maintenance track, > you forked from the tip of master that is preparing for your next > feature release that is release 1.4. > > Even if you realized that the fix is important enough to warrant > applying to the maint-1.0 maintenance track, you cannot merge the > topic that houses 7-patch series down to the old maintenance track > without bringing all the new features that happened since 1.0 on the > master track. > > A kosher way may be to rebase the 7-patch series to maint-1.0 and > merge the result into the maint-1.0 track (and upwards if needed). > But cherry-picking the commit that merged the original "fix" topic > into master _may_ be simpler, as you need to resolve a larger > conflict but (hopefully) only once, instead of up to 7 times, once > per each commit on the "fix" topic while rebasing. > > But of course if something goes wrong, it makes the result > impossible to bisect---exactly the same reason why you should think > twice before doing a "merge --squash". In addition, if you somehow > figured out why the cherry-picked fix was inadequate, you'd now need > to forward-port the fix for the fix to the master track or whereever > the cherry-picked-merge was taken from. > > On the other hand, if the original "fix" branch was rebased on > maint-1.0 and then further fixed, the result can be merged to > maint-1.0 as well as all the way to the master track. > > So, I can understand why people may want to cherry-pick a merge, > I suspect it is a false economy. Optimizing for picking, paying > higher price when the result of (incorrect) picking has to be > corrected later. You may call this "failed to plan ahead", but for us it's a deliberate decision to work this way. Developers work exclusively on main, and merge their branches to main, always. Release management decides later (sometimes much later) which of these branches are cherry-picked to which release branches. We never merge back from a release branch to main. And we prefer single-commit cherry-picks of the merge commits because it makes the history of the release branches easier to read. Bisectability is not an issue; developers bisect failures on the main branch. (Yes, I'm aware that there may be cases where a defect manifests itself differently (or not at all) on main than on the release branch, but these are so rare that it hasn't been an issue for us so far.) I'm not saying I'm very happy with this workflow, it wasn't my decision. And in particular I'm not trying to argue which workflow is better than the other; all I'm saying is that there are teams who decide they want to cherry-pick merge commits, so git should continue to allow it. This is only in response to your earlier "If I were simplifying this, I would probably [...] disallow cherry-picking a merge". (Side note: my main gripe about cherry-picking in general is, of course, that it makes it impossible to use "git branch --contains" or "git tag --contains" to find out which releases contain a given bug fix; but that's a problem no matter whether you cherry-pick the merge commit, or replay the branch on maint and merge it there again.) -Stefan
