Hacker News new | ask | show | jobs
by jolmg 58 days ago
> It matters (to me) because `wget`/`curl` plus `patch` is not some exotic lab setup.

If the point is to be able to do `curl https://...deadbeef.patch | patch -p1`, you can just change the extension provided to Github from `.patch` to `.diff`. That way, it just includes the hunks. E.g.

https://github.com/torvalds/linux/commit/dca922e019dd758b4c1...

I don't see it as a problem with the email format, because I can't imagine someone just patching from an email without looking at the email first.
1 comments
jolmg 57 days ago
I've changed my mind regarding the email format not being a problem. I was thinking of emailed git commits as this ad-hoc thing, but I forgot that `git-format-patch` and `git-am` exist. It's not just an incompatibility between them and `patch`. If you have a line `---` in your git commit message, `git-format-patch` will not somehow escape it, resulting in git-am truncating your git commit message. The email commit format is kinda bad. Github `.patch` exports are just being compatible with `git-am`, so I don't think it's a bug with them.

This is Re:

> I do not yet know whether the bug belongs to GNU patch, GitHub’s .patch export, or the broader patch-format contract.

I don't think this is a problem with GNU patch or the patch format per se, just the emailed commit format. I think the patch format's good because it allows it to be embedded in other texts and also allows comments or extended syntax between hunks. For example, the lines

  diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
  index 15ba592236e845..725a49a0eee72e 100644
not being part of the hunk and probably being seen as a comment by `patch`.

Simply changing `git-am` to accept commit messages being indented in the email format would allow Github fix the issue of their .patch exports being incompatible with `patch`, in addition to fixing that bug about commit messages being truncated when they have a `---` line.

link