How do you keep tabs on commits that fix issues?

[Bryan Richter]

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 <ben at smart-cactus.org> wrote:

> Bryan Richter via ghc-devs <ghc-devs at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20231016/3c4b7d26/attachment.html>