How do you keep tabs on commits that fix issues?

[Alan & Kim Zimmerman]

I know if I backport anything I use 'git cherry-pick -x' which puts a
reference to the original commit in the message.
I am not sure how general that is though

Alan

On Thu, 28 Sept 2023 at 21:55, Justin Bailey <jgbailey at gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/df75d815/attachment.html>