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