Yah, I get very confused with how ghc manages commits. I've ended up searching for the patches at times. I'd love a sensible approach.
On Thu, Sep 28, 2023, 17:55 Justin Bailey <jgbai...@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@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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs