Re: [PATCH (resend)] gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches

From: Jakub Narebski <jnareb@gmail.com>
Date: Apr 5, 2007, 22:58 UTC
Message-ID: <200704060058.24524.jnareb@gmail.com>
In-Reply-To: <7v3b3epn0a.fsf@assigned-by-dhcp.cox.net>

DJunio C Hamano wrote:

Show 18 quoted lines

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> git_patchset_body needs patch generated with --full-index option to
>> detect split patches,...
>> ...
>> This patch fixes this bug in git_blobdiff (in "blobdiff" view).
>>
>> Junio, you probably have missed this patch in the noise...
> 
> Probably.  Although I do remember seeing the patch, it was
> unclear why --full-index is needed (and it still is unclear to
> me).  Do you have a parser that expects/depends on full
> 40-hexdigit hash on the index line?
> 
> Not a complaint but a question -- I do not mind (actually prefer,
> probably) if gitweb worked on full 40-hexdigit internally to
> avoid possible ambiguity issues, although the output may need to
> be truncated to save people from having to see unneeded precision.

Yes, the parser (in git_patchset_body subroutine) checks for presence of fully expanded 40-hexdigit hash, and compares it with the fully expanded 40-hexdigit hash it has in $difftree hashref (from the "raw" diff output, or "raw" part of diff output, or hand-crafted "raw" diff output). It is needed only for the 'html' format case (for "commitdiff" / "blobdiff" view), for git_patchset_body to know what values use for hyperlinking and replacements.

The output is truncated (and hyperlinked) in 'html' format case.

I could have relaxed the parser, and compare up to the precision of hash in the "^index ..." line of extended git diff header in "patch" diff output...

-- 
Jakub Narebski
Poland