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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:17

Paul Mackerras [off-list ref] writes:
quoted hunk
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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:17


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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help