Stefan Haller <lists@xxxxxxxxxxxxxxxx> writes: > And we prefer single-commit cherry-picks of the merge commits because it > makes the history of the release branches easier to read. I would have expected that "git log --first-parent" would give you the same "easy-to-read" history as a run of squached cherry-picks. It of course takes some discipline to ensure that the first-parent chain is kept meaningful, but "never merge, always cherry-pick the merges of topics" also already takes some discipline, so I do not see either workflow has much upside with respect to this point. > 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". Sure. I thought it was fairly obvious to everybody that I was not "simplifying this", at least unilaterally, so raising a concern like you did was the right thing ;-). > (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.) Correct for the "cherry-picking", but not necessarily for a "rebase and merge". You can have (1) a "fix" based on the "main", and (2) the backport of the same "fix" rebased on the "maint", the latter of which has likely been spawned after the former was merged to "main". You can merge the "rebased fix" to the "maint" *as well as* to the "main". If we think about it, that is a natural thing to do. By rebasing "fix" to "maint" to create "rebased fix", we are "correcting" an earlier mistake of basing the fix on a wrong (iow, too recent) point, so after such a rebase, we treat the rebased result as the primary thing. After that, "contains" will do the right thing for the "rebased fix", which is now the primary fix, and shows both "main" and "maint" has it. Of course, a project can choose to adopt a workflow that refuses to obtain such a benefit (presumably for other reasons that gives benefits that outweigh the "sigh, we cannot merge but have to cherry-pick, with all the inconveniences").
