From: Junio C Hamano <gitster@pobox.com>
To: Paul Mackerras <paulus@samba.org>
Cc: git@vger.kernel.org
Subject: Re: filenames with " b" in them create confusing git diff-tree output
Date: Wed, 20 Jun 2007 12:59:40 -0700 [thread overview]
Message-ID: <7v4pl2v1lf.fsf@assigned-by-dhcp.pobox.com> (raw)
In-Reply-To: <18041.3163.329391.298926@cargo.ozlabs.ibm.com> (Paul Mackerras's message of "Wed, 20 Jun 2007 21:15:39 +1000")
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.
next prev parent reply other threads:[~2007-06-20 19:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-20 11:15 filenames with " b" in them create confusing git diff-tree output Paul Mackerras
2007-06-20 19:59 ` Junio C Hamano [this message]
2007-06-20 20:23 ` Linus Torvalds
2007-06-20 20:50 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v4pl2v1lf.fsf@assigned-by-dhcp.pobox.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox