Backporting [was Re: [PATCH v2 1/2] libstdc++: Fix error handling in filesystem::equivalent [PR113250]]

[Jonathan Wakely <jwakely@redhat.com>]

On Thu, 11 Jan 2024 at 10:56, Ken Matsui <kmatsui@gcc.gnu.org> wrote:
>
> On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely <jwakely@redhat.com> wrote:
> > On Thu, 11 Jan 2024 at 09:43, Ken Matsui <kmatsui@gcc.gnu.org> wrote:
> > >
> > > This patch made std::filesystem::equivalent correctly throw an exception
> > > when either path does not exist as per [fs.op.equivalent]/4.
> >
> > Thanks, OK for trunk and all active branches (let me know if you need
> > help backporting it).
> >
>
> Thank you for your review as always!  I do not know how to backport this
> to the active branches.  I think the following page is explaining it,
> but I am not sure how I can know all the active branches.
>
> https://gcc.gnu.org/wiki/GitCookbook#backport

Supported releases are listed on the front page at gcc.gnu.org, the
active branches are currently releases/gcc-11, releases/gcc-12 and
releases/gcc-13.

>
> Do we basically want to git checkout & gcc-backport for each branch
> after this patch is committed to the trunk?

Almost. I use gcc-backport for the newest release branch
(releases/gcc-13) and then I just use 'git cherry-pick' to cherry-pick
the gcc-13 commit onto gcc-12, and then cherry-pick the gcc-12 commit
onto gcc-11.

The reason for this is that there might be some changes needed on a
branch, either to resolve conflicts, or because of other differences
on the branch. e.g. when I did 'git gcc-backport 74a0dab18292be' to
backport that to gcc-13 I had to remove the changes to
include/bits/version.* and edit include/std/version instead (because
we do feature test macros differently on trunk).

If I then wanted to backport it to gcc-12 and I just did 'git
gcc-backport 74a0dab18292be' again in the gcc-12 branch, I would have
to resolve the same conflicts again. If I do 'git cherry-pick
c5ef02e5629f8c' instead (using the hash of the commit on the gcc-13
branch) then it will apply cleanly to gcc-12, because I'm using the
commit that already has the conflicts resolved.

Then if I want to backport to gcc-11 as well, use cherry-pick with the
hash from the gcc-12 branch.

This way any fixes that were needed for branch N-1 will get backported
to N-2 as well. Sometimes this doesn't matter, e.g. the trunk commit
might apply cleanly to every branch. But sometimes the commit needs
slightly more massaging to apply to each older branch, so doing it
trunk->13 then 13->12 then 12->11 tends to work better.

The reason I use cherry-pick after the first backport (instead of
gcc-backport every time) is because I don't want a second "(cherry
picked from commit ...)" line to be added to the commit message.
That's added by gcc-backport (by using cherry-pick -x) but we only
need to add it once to be able to track the provenance of the
backport, to know which trunk patch was backported.

If cherry picking a backport fails and creates a mess of conflicts and
you just want to give up and start again, 'git cherry-pick --abort'
will undo the changes and leave the working tree clean again. This
works whether you use gcc-backport or cherry-pick (because
gcc-backport just uses cherry-pick).