# git-diff/git-format-patch safe for GNU (or POSIX) patch? 5 messages from 2008-06-26 to 2008-06-26. Participants: Flavio Poletti, Karl Hasselström, Petr Baudis. Thread: https://gitlist.dev/t/14162 ## Flavio Poletti, 2008-06-26 10:27 Subject: git-diff/git-format-patch safe for GNU (or POSIX) patch? Message-ID: <58230.213.203.159.164.1214476059.squirrel@upmail.polettix.it> URL: https://gitlist.dev/e/58230.213.203.159.164.1214476059.squirrel%40upmail.polettix.it ``` Hi, I had to dig a problem in Glib ("base" library for GTK) in Debian Etch recently and I decided to manage changes/diffs with git. It's just so easy to use and avoids all the usual copy-the-tree-then-diff that I used before. When I was happy with the modifications, I used git-format-patch to produce the message and the patch to send. I then saw that the format is a little different with respect to what diff -u produces; in particular, I noticed that there was an added line between the "diff --git..." line and the one stating the "origin" file: diff --git a/glib/gstrfuncs.c b/glib/gstrfuncs.c *** this one *** index 61d11ed..7786f10 100644 --- a/glib/gstrfuncs.c +++ b/glib/gstrfuncs.c Moreover, each chunk's header contained added stuff, like the "g_ascii_strtoll..." stuff in the following example line: @@ -813,6 +813,8 @@ g_ascii_strtoll (const gchar *nptr, Before sending the patch, I tried to "reverse" these "deviations" from the normal diff output, but I was quite sure there was no need to do this. I then tried to use GNU patch with the unaltered message, and it seemed quite happy with all the extra stuff. Just to be on the safe side, I tried to look for: 1. the "official" unified diff spec 2. a description of what patch is willing to consider valid input 3. some notes about how git-diff copes with patch compatibility 4. some hints to use git for working on projects that do not use any other VCS, or for which one only wants to produce and send a quick patch starting from a tarball. I had no luck with the first two attempts, and a moderate luck with the third: there is more than one email from Junio C. Hamano either stating that git-diff strives to be nice with patch, or containing patches to address possible conformance issues. I was also quite unluck with the fourth attempt, even if this is surely due to my poor websurfing-fu. Anyway, the messages from Mr. Hamano kind-of answer the question in the subject, but in a somehow "implicit" way rather than explicitly. In particular, I wonder if there is any document about how a "valid" unified diff should look like (including optional valid extensions) that was used as input and reference for git-diff development. Or had you just to figure it out from diff/patch sources? Thank you, Flavio. ``` ## Karl Hasselström, 2008-06-26 10:36 Subject: Re: git-diff/git-format-patch safe for GNU (or POSIX) patch? Message-ID: <20080626103607.GA16525@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20080626103607.GA16525%40diana.vm.bytemark.co.uk In-Reply-To: <58230.213.203.159.164.1214476059.squirrel@upmail.polettix.it> ``` On 2008-06-26 12:27:39 +0200, Flavio Poletti wrote: > When I was happy with the modifications, I used git-format-patch to > produce the message and the patch to send. I then saw that the > format is a little different with respect to what diff -u produces; > in particular, I noticed that there was an added line between the > "diff --git..." line and the one stating the "origin" file: > > diff --git a/glib/gstrfuncs.c b/glib/gstrfuncs.c > *** this one *** index 61d11ed..7786f10 100644 > --- a/glib/gstrfuncs.c > +++ b/glib/gstrfuncs.c patch ignores any junk it doesn't understand, including this line. > Moreover, each chunk's header contained added stuff, like the > "g_ascii_strtoll..." stuff in the following example line: > > @@ -813,6 +813,8 @@ g_ascii_strtoll (const gchar *nptr, You get this by giving the -p flag to GNU diff; git diff just does it by default, is all. > 4. some hints to use git for working on projects that do not use any > other VCS, or for which one only wants to produce and send a quick > patch starting from a tarball. You can use git/contrib/fast-import/import-tars.perl to import the last few releases into git (possibly just the last release, if you don't need the history) and then just build on that, and send patches back to the project when you're done. When the project makes another release, use import-tars to import the new tarball, and then rebase if you have any patches they haven't accepted yet. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ``` ## Flavio Poletti, 2008-06-26 11:49 Subject: Re: git-diff/git-format-patch safe for GNU (or POSIX) patch? Message-ID: <58284.213.203.159.164.1214480989.squirrel@upmail.polettix.it> URL: https://gitlist.dev/e/58284.213.203.159.164.1214480989.squirrel%40upmail.polettix.it In-Reply-To: <20080626103607.GA16525@diana.vm.bytemark.co.uk> ``` Thanks for the feedback! I wonder if this feature of patch "ignoring" stuff it doesn't understand is a GNU feature or a POSIX feature, but I'm abusing your patience here. (Incidentally, I also saw that POSIX has no "unified" format, but this "ignoring" feature might apply in a wider sense). >> 4. some hints to use git for working on projects that do not use any >> other VCS, or for which one only wants to produce and send a quick >> patch starting from a tarball. > > You can use git/contrib/fast-import/import-tars.perl to import the > last few releases into git (possibly just the last release, if you > don't need the history) and then just build on that, and send patches > back to the project when you're done. > > When the project makes another release, use import-tars to import the > new tarball, and then rebase if you have any patches they haven't > accepted yet. Importing wasn't actually an issue, just a matter of init/add/commit. I was more scared about the patch production process, i.e. producing a patch that could be perfectly usable by the project's maintainers. But given what you kindly said, I think I can dismiss this as excess of caution by me. Thanks, Flavio. ``` ## Karl Hasselström, 2008-06-26 12:49 Subject: Re: git-diff/git-format-patch safe for GNU (or POSIX) patch? Message-ID: <20080626124927.GA17731@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20080626124927.GA17731%40diana.vm.bytemark.co.uk In-Reply-To: <58284.213.203.159.164.1214480989.squirrel@upmail.polettix.it> ``` On 2008-06-26 13:49:49 +0200, Flavio Poletti wrote: > Importing wasn't actually an issue, just a matter of > init/add/commit. I was more scared about the patch production > process, i.e. producing a patch that could be perfectly usable by > the project's maintainers. But given what you kindly said, I think I > can dismiss this as excess of caution by me. Yes, patch is one of the most permissive programs around. It will eat _anything_. (And throw up on the carpet if it was just too wrong.) There are two things in git patches that patch won't grok: rename/copy patches, and binary patches. Neither feature is on by default, IIRC -- you have to give command line flags -- precisely so that "git diff" default output will be patch compatible. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ``` ## Petr Baudis, 2008-06-26 13:44 Subject: Re: git-diff/git-format-patch safe for GNU (or POSIX) patch? Message-ID: <20080626134400.GC12567@machine.or.cz> URL: https://gitlist.dev/e/20080626134400.GC12567%40machine.or.cz In-Reply-To: <58284.213.203.159.164.1214480989.squirrel@upmail.polettix.it> ``` On Thu, Jun 26, 2008 at 01:49:49PM +0200, Flavio Poletti wrote: > Thanks for the feedback! I wonder if this feature of patch "ignoring" > stuff it doesn't understand is a GNU feature or a POSIX feature, but I'm > abusing your patience here. (Incidentally, I also saw that POSIX has no > "unified" format, but this "ignoring" feature might apply in a wider > sense). As you say, POSIX does not specify unified diffs at all. I'm not sure if patch's policy is as relaxed for other formats and I didn't find any mention of this relaxed policy in the SUS spec, but unified diffs with extraneous information intertwined are extremely widespread; about any VCSes out there append extra information to the diffs. Incidentally, does anyone actually know about _any_ other patch tool in the wild that is _not_ based on the original Larry Wall's patch? -- Petr "Pasky" Baudis The last good thing written in C++ was the Pachelbel Canon. -- J. Olson ```