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
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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs