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!
