How do you keep tabs on commits that fix issues?

[Andreas Klebinger]

Personally I try to include fixes #1234 in the commit so then I can just
check which tags contain a commit mentioning the issue.

If the issue isn't mentioned in the commit I usually look at the issue
-> look for related mrs -> look for the commit with the fix -> grep for
the commit message of the commit or look for the marge MR mentioned on
the mr.

Am 28/09/2023 um 08:56 schrieb Bryan Richter via ghc-devs:
> 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