Re: kompare won't parse git diffs
On Wed, 2 Aug 2006, Jakub Narebski wrote:
>
> What about filenames with end-of-line character in them? Is it quoted?
I would _not_ guarantee that git handles filenames with newlines in them correctly in all cases (I won't guarantee tabs either, but the likelihood is much higher ;). But yes, "git diff" does handle it right.
That said, yes, it should be quoted. A quoted filename in "git diff" not only changes a newline into the normal quoted sequence (ie "\n"), but will also put the whole filename in quotes.
So if you have a file called "hello", the diff headers will say
--- a/hello
+++ b/hello
but if you have a file with an embedded newline, it would look something like
--- "a/hello\nthere"
+++ "b/hello\nthere"
(where a '"' in a filename causes the same quoting to take effect, so if you haev embedded double-quotes in a filename, it would be shown as something like
--- "a/embedded\"quote"
+++ "b/embedded\"quote"
instead).
> BTW. It should be not that hard to get filename with spaces and tabs even
> in GNU diff format: everything up to last <tab> is filename.
That's true _if_ you know that the patch was generated by GNU diff, but since you can't know that (since GNU diff doesn't add any markers of its own), you cannot know if it's a patch generated by an old version of diff (for a filename with a tab inside of it) or if it's a filename with the GNU date extensions.
Show 11 quoted lines
> > Now, if the kompare people can show that every single other patch
> > generator adds the stupid tab + date format, I guess we could do it too,
> > but
> > (a) there is no valid date in general to use, so it's a fundamentally
> > broken notion and
>
> Meaning we don't save timestamp in git ;-) Well, we could use date of the
> commit which created given file contents (first commit from root, or last
> from head which contains given version)... but the same contents might be
> introduced independently in different commits. And different clones of the
> same repository might have different commit dates...
Exactly, a "date" in _any_ distributed SCM makes no sense what-so-ever. What happens across a merge? Which date do you take? Do you follow the thing down and basically do a full "annotate" on the file?
The fact is, dates in SCM diffs are insane and stupid. They do not make sense in the presense of an SCM, and they only make sense on individual _files_ (and quite limited there too, but at least it has _some_ meaning).
In the SCM, the _changes_ may have timestamps, but the files sure as hell should not. Of course, a file-based SCM easily gets confused about these things (eg in CVS, there is very much a 1:1 relationship between files and changes, so in the CVS mindset it can make sense - but that's because CVS is stupid to begin with, and the problem really goes much deeper than timestamps on the diffs).
Linus
