Forge pull/merge requests bi-directional sync

[Robin Jarry]

Hey Johannes,

Thanks a lot for your reply.

Johannes Schindelin, Mar 16, 2025 at 18:31:
> You see, I do like the convenience _and_ power of Pull Request because
> they let me _work_ with the changeset, which emails distinctly do not: I
> cannot change the color, I cannot expand the hunk context lines, I cannot
> switch to a word diff, I cannot ignore indentation changes, I cannot
> search the entire code base for callers ofthe code touched by the
> hunk, I cannot check out and compile the code. And the list goes on and on
> and on.

I agree that it requires more local tooling in order for patches sent
via email to be less crude.

As I mentioned in my message, my goal wasn't to determine what process
is best. I simply would like to minimize the gap between users of both
of these paradigms without forcing them to adhere to a process they
don't want to use for $reasons and/or $opinions.

> While I object to using judgmental language such as calling this
> "pathological" (but I grant you that this kind of language seems to be
> accepted on this here mailing list, for example, I cannot count the times
> I've seen other people's actions be characterized as "misguided", "overly
> aggressive", or applying similarly unkind expressions, and regretted my
> life choices), it is indeed a good example how this is a "footgun" for
> GitGitGadget users: The most natural thing to do on a Pull Request (or
> Merge Request) is to reply to other people by adding a comment.

I didn't want to be judgemental and now I realize that my tone was
probably negative. I hope you will excuse me for this. I can sense that
you had bad experiences in mailing lists. I know for a fact that some
are worse than others. To be fair, this isn't inherent to mailing lists.
I have seen people being asses on GitHub as well :)

My goal was to highlight that GitHub users are second class citizens and
are forced to use emails for replying to comments even if they would
prefer responding to pull requests.

> For the record, there have been some ideas floating around how to address
> this, see e.g. https://github.com/gitgitgadget/gitgitgadget/issues/154,
> but keep in mind that the problem is fundamentally not solvable: In some
> instances, users have simply replied without quoting any text, and only
> human users can figure out from the context to which email any given
> comment intended to reply (I guess if I were sufficiently advanced at
> using LLMs, I could automate that, but I am not).

I don't know much about GitHub but isn't there a way to determine the
source code lines that are commented/replied to? For non-code comments
without any context, maybe try to fallback on the most recent non-code
comment. The important aspect would be to use proper In-Reply-To and
References headers not to break email threading.

> That would either require GitHub accounts for all of the contributors on
> the Git mailing list (good luck with that, there are opinions, _opinions_
> I say, on this list), or the unfortunate case where `gitgitgadget` would
> be recorded as PR author for those (and your guess is as good as mine what
> people who choose not to have a GitHub account would have to say about
> seeing their contributions mirrored and reviewed on GitHub...).

Email replies to patches are already mirrored on GitHub as comments made
from the gitgitgadget bot. I don't think that mirroring full patch sets
would be that different, authorship wise.

Of course that would need to be part of the contributing guidelines of
projects that decide to enable mirroring.

> And then there is obviously the fundamental lack of information in most
> patch contributions regarding what commit they are meant to be applied to.

This isn't a big issue as most (email based) projects require that
patches are applied to the default HEAD branch.

If the patches target another branch, they often have special subject
prefixes (e.g. [PATCH stable/24.11]). But in my opinion, these are
corner cases.

> A highly-esteemed former teammate of mine once had an internal repository
> where they automated such a patch -> Pull Request mirror, and it worked a
> lot better than I had anticipated, so maybe it's not that bad. At the same
> time it turned out to be less relevant to our team processes than
> previously thought, therefore it remained a proof-of-concept and was
> retired.

I would be curious to see what it looked like. If there is any trace
left of that proof-of-concept ;)

> I gave you a lot of opinions above, and most of them seem to be in
> disfavor of this idea.
>
> To counter that, I feel the need to stress that these are _merely_ my
> personal opinions, biased by my dislike for the limitations of an
> email-based workflow (and the way people invariably seem to treat each
> other in those). And my frustrations clearly stand in the way of any
> desire I could possibly feel to address your suggestions myself. That's
> just _me_, though, and I don't really put much stock anymore in individual
> opinions, even my own.
>
> So let me stress this: If you were to work on integrating Patchwork and
> GitGitGadget and opened a Pull Request (or even sent a patch to this here
> mailing list), I would of course be delighted to accept it.

Thanks a lot for your input, Johannes!

I'd be curious to know if anyone in the patchwork community (or anyone
actually using email to contribute patches anywhere) would be interested
in closing the gap between worlds.

Cheers.

-- 
Robin

> No running on pool deck.