How do you keep tabs on commits that fix issues?

[Ben Gamari]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230929/81fac79d/attachment.sig>