Re: kompare won't parse git diffs

[Jakub Narebski <jnareb@gmail.com>]

Linus Torvalds wrote:

> On Wed, 2 Aug 2006, Jakub Narebski wrote:
>
>> > 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).

What about putting e.g. sha1 (or abbreviated sha1) of blob if file exist 
in repository, "(in index)" or "(working area)" in two other cases, instead
of date or file version?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git