Bruno Haible <br...@clisp.org> writes: > Sam James wrote: >> Could I propose that cherry-picks to the stable-XXX branches are done >> with 'git cherry-pick -x'? This is often done in projects following a >> gnulib-like model. >> >> git will append '(cherry picked from commit ...)' to the commit message >> which makes it easy to compare with the original commit and distinguish >> branch-only commits from backports. > > All commits to the stable branches [1] are backports. There are no commits > that are created for the branch specifically. > > But while doing these backports, I have to make several adjustments: > - Combine 2 or more commits from 'master' if the first of these commits > introduced a regression that was only fixed later on. > - Assign new '# serial' numbers to the *.m4 files. > - Omit modifications to modules that did not exist when the stable branch > was forked off. > - Omit documentation changes that don't apply. > - Fix merge conflicts. > - For stable branches from the previous year: Update the (C) year > of each modified file. > > I don't think that a tool like 'git cherry-pick' will allow me to have > the needed flexibility for this process.
Ah, so, in a way, this is precisely why the line is useful, because they're *not* direct cherry-picks and it's useful to be able to correspond them to what the mainline change(s) were. But if you're not using 'git cherry-pick' already for these, then I can understand it's a big workflow change and probably not worth it. The expectation isn't that it directly matches the 'cherry-picked from ...' commits, but rather that it gives some anchor to compare to / expresses intent, rather than having to compare just the commit summary (as those aren't unique). > > Bruno > > [1] https://www.gnu.org/software/gnulib/manual/html_node/Stable-Branches.html
