How do you keep tabs on commits that fix issues?

[Justin Bailey]

I would also love to know how to do this. I don't often contribute to GHC,
but I follow bug fixes closely. In fact, the one time I did contribute (
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10245), it turned out i
was duplicating work already done elsewhere! If I had known how to
understand if the issue I wanted fixed (
https://gitlab.haskell.org/ghc/ghc/-/issues/22516) was backported, it would
have saved me and the maintainers' time.

On Wed, Sep 27, 2023 at 11:56 PM Bryan Richter via ghc-devs <
ghc-devs at haskell.org> wrote:

> 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.
>
> Thanks!
>
> -Bryan
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230928/3f2e21ae/attachment.html>