9

Anybody know what the "proper" mime-type for patch files would be? I have been using application/octet-stream because I don't see anything better at iana.org. Is application/octet-stream correct, or is there something else that fits better? Why is there no application/patch type?

Obviously, one possible answer is text/plain, but I have seen many patch files which include data which is not purely text. Is text/plain the best choice if you know for a fact all content is text, or is it better to be consistent across all patch files?

I should say the context I am mainly thinking about this in is setting mime-type as a clue to subversion about handling line-endings (svn:mime-type and svn:eol-style). The issue is that a patch file may patch both files which use eol-style native as well as non-native, which can lead to line-ending weirdness when applying a patch post-checkout.

Melebius
  • 6,183
  • 4
  • 39
  • 52
Cameron Brown
  • 152
  • 1
  • 8

3 Answers3

11

I couldn't find an authoritative version either. Here's some other possibilities:

  • text/x-diff
  • text/x-patch
  • application/x-patch

For what it's worth, Trac (a ticket tracker with good svn support) uses text/x-patch for diffs. git.kernel.org and GitHub use text/plain.

jwhitlock
  • 4,572
  • 4
  • 39
  • 49
1

If your patch only contains text, I would prefer text/plain over text/x-patch or text/x-diff. IMO, text/x-patch or -diff is more suitable for this purpose, and is recommended by some projects, but the main reason for text/plain is compatibility.

In Gmail if the attachment is text/plain, when you click it it will automatically pop up a document preview; but it will not for text/x-patch or text/x-diff. Another example is the archive interface of Mailman (a popular mailing list management software): it shows the text with text/plain, but does not with text/x-patch.

If your patch contains binary data, I would use application/octet-stream, not because it is correct but it will save you some trouble from line endings.

Timothy Gu
  • 3,727
  • 28
  • 35
0

I'm curious why you are checking in patch files to SVN. That aside, I would go with the assumption that if you have the possibility of checking binary patch files to use application/octet-stream. I'm not sure what would happen if you mixed them... text for text, octet for binary... that might also be possible?

DaveShaw
  • 52,123
  • 16
  • 112
  • 141
  • 2
    Patch files are commonly used in RPMs for open source products. It's a SCM-agnostic way to keep local modifications discrete from upstream source. I check in a good number of those. – Cameron Brown Mar 02 '11 at 01:08
  • It's easy to keep patches of text files separate from patches to binary files for patches that YOU create. In fact I never create patches with binary parts. But others create them sometimes. And if you're managing them, seems like you shouldn't need to do an analysis of the actual contents of a file to discover whether you need text/plain(?) or application/octet-stream. That's why I think application/patch makes sense. A patch file can be a mix of text and binary with special EOL translation requirements. Maybe patch files should include a mime-type descriptor for each of their components? – Cameron Brown Mar 02 '11 at 01:29