You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pretty much from the start I've been relying on the idea that git show was adding a line composed of a single space before and after the commit message.
As it turns out, that never happened, or happens. Instead less does that1 (also delta though that's less of a concern and it does other weird stuff). So I've been relying on a thing which never happened assuming it would make my parser more resilient against user mistakes, and instead it made things more wonky and less reliable.
Footnotes
and even better it apparently only does that when printing to the terminal, if it's piped out of then the content is fine ↩
The text was updated successfully, but these errors were encountered:
Hopefully this is the last fix to the patcher. From the start of the
implementation I relied on the idea that `git show` was adding a line
composed of a single space (and a newline) before and after the patch
message, as that is what I observed in my terminal, and it's
consistent with RFC 3676 signatures (two dashes, a space, and a
newline).
Turns out that single space, while present in my terminal indeed, was
completely made up by `less(1)`. `git show` itself doesn't generate
that, neither does it appear when using most pagers, or even when
piping the output of `less` into something (a file, an other pager,
...). It's pretty much just something `less(1)` sends to a terminal
during interactive sessions to fuck with you.
Fixes#1037
Pretty much from the start I've been relying on the idea that
git show
was adding a line composed of a single space before and after the commit message.As it turns out, that never happened, or happens. Instead less does that1 (also delta though that's less of a concern and it does other weird stuff). So I've been relying on a thing which never happened assuming it would make my parser more resilient against user mistakes, and instead it made things more wonky and less reliable.
Footnotes
and even better it apparently only does that when printing to the terminal, if it's piped out of then the content is fine ↩
The text was updated successfully, but these errors were encountered: