Repository navigation
Emails are rendered using post-processed markdown, not raw text #1271
Description
When turning a PR description into a cover letter, GGG appears to convert the post-processed Markdown's text into the message, instead of putting the raw PR description's text. However, I'd expect that the raw text to be sent instead.
Caveat: I'm mostly going off my memory here; I haven't been burned by this in a while, because I've been checking that the Markdown accurately reflects what I want to send. I'm also having trouble finding good examples where I got affected by this - I think the mangled table in https://lore.kernel.org/git/kl6l4k04iw5y.fsf@chooglen-macbookpro.roam.corp.google.com/ is one.
Concretely, I believe this means that if I have
# FOO
in my PR description [1], it gets rendered as:
FOO
in the cover letter, but I'd want the literal # .
- Not to get too meta about this, but this also means that the contents of the ``` code block get inserted literally into cover letter and the literal ``` gets dropped.
Activity
dscho commentedon Aug 14, 2023
Well, the PR description is Markdown, but emails are plain text...
And with the Markdown-averse/AsciiDoc-loving Git crowd, a
# HEADERwould maybe not be understood.Therefore I don't think it would be a good idea to paste the PR description verbatim. We may want to hack up the md2text renderer to present headers differently instead, I can see that. But pasting Markdown verbatim? We don't want to do that.
dseomn commentedon Mar 2, 2025
Would it make sense to just require PR descriptions to be a single ```-enclosed block, then email the contents of that block? That way the view on github and in an email would be pretty similar.
I think I just got bitten by this in git/git#1901 but I can file another bug if this is caused by something else:
got emailed as
and
as
dscho commentedon Mar 2, 2025
But wouldn't that be fixed if the PR description was marked up accordingly (and make the description of the actual PR nicer to read, too)? Something like this:
Previously, some calls to for-each-ref passed fixed numbers of path
components to strip from refs, assuming that remote names had no slashes
in them. This made completions like:
Result in:
With this patch, it instead results in:
In addition, the change to __git_dwim_remote_heads() restricts it to
only list remote branches, not HEAD. I think that actually improves the
completion where it's used though, since HEAD doesn't seem to be valid
anyway:
CC: Jacob Keller jacob.keller@gmail.com, Junio C Hamano gitster@pobox.com
dseomn commentedon Mar 2, 2025
Yeah, that would work too. I was just a bit surprised that the presentation on github mattered at all since the canonical form is in the email. (And I've since realized that roundcube has an option called "Keep formatting" that I think makes it work with patches, so I'll probably just use that going forward if it works.)
dscho commentedon Mar 3, 2025
Well, my thinking was: so many Git users are used to modern practices like Gitlab Merge Requests and GitHub Pull Requests, and so not used to the quaint mailing list-based development process, that it would make sense to try to map the PR experience as much to the patch series as possible, including the representation of the PR (which, by definition, cannot use any meaningful markup on the mailing list, certainly not if the requirement is "No HTML or else!").
dseomn commentedon Mar 3, 2025
That probably is the right choice, I might be an unusual case. I used to use the list-based workflow a lot so I'm reasonably familiar with it, but I was only expecting to make one patch to git and didn't feel like setting up
git send-emailor reconfiguring Thunderbird for only one patch.