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

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

[Paul Mackerras]

While trying to improve gitk's handling of filenames with spaces, I
realised that the header line in git diff-tree's output can be
inherently ambiguous, since it doesn't put quotes around filenames
with spaces (although it does for filenames with other special
characters in them).

For example:

paulus@quango:~/gitk/testrepo$ mkdir "test b"
paulus@quango:~/gitk/testrepo$ cat >"test b/foo"
stuff
paulus@quango:~/gitk/testrepo$ git add "test b/foo"
paulus@quango:~/gitk/testrepo$ git commit -a
Created commit 71a3074: Add a "test b" directory
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 test b/foo
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. :)

Would there be any ill effects from quoting filenames with spaces, do
you think?  It seems the simplest fix to me (and I will make gitk
handle quoted filenames, which it doesn't at present :).

Paul.

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

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> writes:

> 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.

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

[Linus Torvalds]

On Wed, 20 Jun 2007, Junio C Hamano wrote:
> 
> 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 ;-)

Well, in all fairness, I *did* hate having to write the code to handle all 
the name handling in git-apply.

Escaping whitespace (or at least giving the _option_ to do so) might well 
be a good way to not have to be as smart as git-apply is.

git-apply didn't have that option, since git-apply has as one primary 
motivation the need to be able to handle patches that come from non-git 
sources, so git-apply goes to quite some extreme lengths to try to make 
sense of an inherently rather ambiguous format (that the git diffs then 
*made* unambiguous, but using pretty subtle rules in order to stay 
compatible).

Some maybe we should have some generic method of asking for any filename 
to be quoted in particular ways?

		Linus

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Some maybe we should have some generic method of asking for any filename 
> to be quoted in particular ways?

Probably, especially if you notice there has been a separate
thread whose title begins with a word "Stupid".