On Thu, Jan 11, 2024 at 4:27 AM Jonathan Wakely <jwak...@redhat.com> wrote:
>
> On Thu, 11 Jan 2024 at 12:23, Ken Matsui <kmat...@gcc.gnu.org> wrote:
> >
> > On Thu, Jan 11, 2024 at 3:45 AM Ken Matsui <kmat...@cs.washington.edu>
> > wrote:
> > >
> > > On Thu, 11 Jan 2024 at 11:14, Jonathan Wakely <jwak...@redhat.com> wrote:
> > > > On Thu, 11 Jan 2024 at 10:56, Ken Matsui <kmat...@gcc.gnu.org> wrote:
> > > > >
> > > > > On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely <jwak...@redhat.com>
> > > > > wrote:
> > > > > > On Thu, 11 Jan 2024 at 09:43, Ken Matsui <kmat...@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.
> > >
> >
> > For the Bugzilla issue, should I update the status to RESOLVED? Or
> > does someone else handle this? Also, are there other things I should
> > do about this issue?
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250
>
> Yes, please close as RESOLVED FIXED and set the target milestone to
> the first release with the fix, which will be 11.5
>
> In cases like this where the fix is backported to multiple release
> branches I also add a comment to say "fixed in 11.5, 12.4, 13.3"
> because otherwise just setting the target milestone to 11.5 doesn't
> tell you about the other branches.
>
> It's also nice to thank the reporter for filing it, especially when
> they identify the root cause and suggest a fix.
>
> And thank you for taking care of it!
>
Done! I truly appreciate your kind step-by-step guidance!
