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

[Ken Matsui <kmatsui@cs.washington.edu>]

On Thu, 11 Jan 2024 at 11:14, Jonathan Wakely <jwakely@redhat.com> wrote:
> 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).
> 

Thank you for the detailed explanation!  I think I was able to backport
the patch to the active branches.

-- 
Ken Matsui