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).
