Re: Parsing diff --git lines
On Sat, 8 Mar 2008, Simon Fraser wrote:
>
> However, I don't see a reliable way to identify the two files
> from a "diff --git" line. Here's a (deliberately pathological)
> example:
See how "git-apply" does it.
The rule is:
- if the filenames are different, you should ignore the filenames on the
"diff --git" line, and trust the ones on the "renamed from/to" ones
(which are unambiguous because they only have one filename per line)
- if the filenames aren't different, then you can unambiguously know how
to parse it by simply making sure they are the same.
So to take your example:
> diff --git a/a / b/file with spaces.txt b/a / b/file with spaces.txt
Here, you can *know* that the filename is "a / b/file with spaces.txt", because it must match the pattern "a/$filename b/$filename", and no other split at a space would ever do that!
See in particular "git_header_name()" in builtin-apply.c. See the comments both at the top of the function and there in the middle to reflect the above rule:
/*
* This is to extract the same name that appears on "diff --git"
* line. We do not find and return anything if it is a rename
* patch, and it is OK because we will find the name elsewhere.
* We need to reliably find name only when it is mode-change only,
* creation or deletion of an empty file. In any of these cases,
* both sides are the same name under a/ and b/ respectively.
*/
...
/*
* Accept a name only if it shows up twice, exactly the same
* form.
*/> What would make this possible would be either to always quote
> file paths containing spaces, or use a character other than
> a space (e.g. a \t) between the two file names.
Well, git didn't originally ever quote filenames at all, and I actually wanted the "diff --git" line to look as much like a regular "diff -urN" line as possible (which has spaces between the names)
These days, we could quote, but hey, anybody who parses diff lines needs to be able to handle the non-quoted form *anyway*, so quoting doesn't really help anybody in the end.
Linus
