I usually end up looking at the source I’m actually compiling and checking if the expected changes are in the source or not. If not, I end up backporting stuff to the source at hand. As this is often for compilers that are way past their end of life cycle (e.g. 8.10), there seems little point in the overhead of upstreaming it.
I do agree with Alan that chery-pick -x is often the right approach to keep track of where things originally came from. I also agree with Andreas that having the ticket ids in the coming message helps when searching. Moritz On Fri, 29 Sep 2023 at 6:27 AM, Andreas Klebinger <klebinger.andr...@gmx.at> wrote: > 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@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
