git-diff/git-format-patch safe for GNU (or POSIX) patch?

git-diff/git-format-patch safe for GNU (or POSIX) patch?

[Flavio Poletti]

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.

Re: git-diff/git-format-patch safe for GNU (or POSIX) patch?

[Karl Hasselström]

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

Re: git-diff/git-format-patch safe for GNU (or POSIX) patch?

[Flavio Poletti]

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.

Re: git-diff/git-format-patch safe for GNU (or POSIX) patch?

[Karl Hasselström]

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

Re: git-diff/git-format-patch safe for GNU (or POSIX) patch?

[Petr Baudis]

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