Re: Suggestion for cherry-picking to stable branches

[Sam James]

Bruno Haible <bruno@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