Re: filenames with " b" in them create confusing git diff-tree output

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 20, 2007, 19:59 UTC
Message-ID: <7v4pl2v1lf.fsf@assigned-by-dhcp.pobox.com>
In-Reply-To: <18041.3163.329391.298926@cargo.ozlabs.ibm.com>

Paul Mackerras <paulus@samba.org> writes:

Show 15 quoted lines

> paulus@quango:~/gitk/testrepo$ git diff-tree -r -p -C HEAD
> 71a3074e723c3e5eb599e6b3c47e3267a3cac3bc
> diff --git a/test b/foo b/test b/foo
> new file mode 100644
> index 0000000..f2e4113
> --- /dev/null
> +++ b/test b/foo
> @@ -0,0 +1 @@
> +stuff
>
> Note how there appear to be 4 filenames on the "diff --git" line.  At
> present gitk will interpret that as a diff between "test" and
> "foo b/test b/foo", since it looks for " a/" and " b/" to delimit the
> filenames.  Of course if the file got renamed it could get even more
> confusing. :)

Your example, "a/test b/foo" vs "b/test b/foo", can be and IS parsed unambiguously by git-apply (you can try "git apply --stat" your example). IOW, the code to correctly handle it already exists ;-)

If you are seeing a rename/copy you would get explicit rename lines between "diff --git" header and "index HEXHEX..HEXHEX" line, what we (i.e. git-apply) do is to make sure the information we get on the "diff --git" header and those on rename/copy lines match. The latter is more reliable, of course, as they are in strictly one-line-per-filename format, and in fact we use the information from there instead of "diff --git" line for rename patches. And for non-rename case, you can find all instances of "b/", and see if what follows to the end of line of which instance of b/ does match what is between "diff --git a/" and that "b/".

In your example, you have three possible "b/" that indicates the beginning of a name:

	foo b/test b/foo
        test b/foo
        foo

The leading part after "diff --git a/" for the above three possibilities are:

	test
        test b/foo
	test b/foo b/test

and you can tell the second one gives the match.

> Would there be any ill effects from quoting filenames with spaces, do
> you think?

It is very common (I would not do that personally but I do not have a strong reason to advise against when people want to do so) to have a space in filenames.