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. -- Ken Matsui
