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 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

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 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

Thanks Ben. I've copied that verbatim to https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#working-conventions :) On Fri, 29 Sept 2023 at 18:23, Ben Gamari wrote:

Bryan Richter via ghc-devs 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