Thanks Ben. I've copied that verbatim to https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#working-conventions :)
On Fri, 29 Sept 2023 at 18:23, Ben Gamari <b...@smart-cactus.org> wrote: > Bryan Richter via ghc-devs <ghc-devs@haskell.org> writes: > > > I am not sure of the best ways for checking if a certain issue has been > > fixed on a certain release. My past ways of using git run into certain > > problems: > > > > The commit (or commits!) that fix an issue get rewritten once by Marge as > > they are rebased onto master, and then potentially a second time as they > > are cherry-picked onto release branches. So just following the original > > commits doesn't work. > > > > If a commit mentions the issue it fixes, you might get some clues as to > > where it has ended up from GitLab. But those clues are often drowning in > > irrelevant mentions: each failed Marge batch, for instance, of which > there > > can be many. > > > > The only other thing I can think to do is look at the original merge > > request, pluck out the commit messages, and use git to search for commits > > by commit message and check each one for which branches contain it. But > > then I also need to know the context of the fix to know whether I should > > also be looking for other, logically related commits, and repeat the > dance. > > (Sometimes fixes are only partially applied to certain releases, > > exacerbating the need for knowing the context.) This seems like a > mechanism > > that can't rely on trusting the author of the original set of patches > > (which may be your past self) and instead requires a deep understanding > to > > be brought to bear every time you would want to double check the > situation. > > So it's not very scalable and I wouldn't expect many people to be able to > > do it. > > > > Are there better mechanisms already available? As I've said before, I am > > used to a different git workflow and I'm still learning how to use the > one > > used by GHC. I'd like to know how others handle it. > > > In general Marge leaves a helpful comment with the final SHA on each > pull request they merge to master. If I want to know whether an issue is > fixed in a stable branch, I will typically: > > 1. find the issue, which should have a reference to the merge requests > which fixed it > 2. from the merge request, find the final commit SHA from Marge's > comment > 3. look for references to that commit SHA in the appropriate branch. > > (3) works because in general we cherry-pick backports with the `-x` > flag, which causes a "(cherry-picked from ...)` comment to be appended > to the commit message. Moreover, reverts should also mention the commit > being reverted. > > Does this help? > > Cheers, > > - Ben >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs