Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@xxxxxxxxx> wrote:
>> Replace "gitweb diff header" with its full sha1 of blobs and replace
>> it by "git diff" header and extended diff header. Change also somewhat
>> highlighting of diffs.
>> 
>> Changes:
>> * "gitweb diff header" which looked for example like below:
>>     file:_<sha1 before>_ -> file:_<sha1 after>_
>>   where 'file' is file type and '<sha1>' is full sha1 of blob is
>>   changed to
>>     diff --git _a/<file before>_ _b/<file after>_
>>   In both cases links are visible and use default link style. If file
>>   is added, a/<file> is not hyperlinked, if file is deleted, b/<file>
>>   is not hyperlinked.
> 
> "Everything clickable underlined" isn't the best way to represent things.
> Anyway, my 2 cents is that I don't like the overly explicit underlineing.
> I liked it the way it was in take 1.

Thet is the only "obviously link" per patch. And I think there should be
at least one non-hidden link.

BTW. comments like this are the reason I've sent the patch as-is, without
resolving the strange filenames problem (it would be nice if somebody was
to send code; well Junio send patch to address core git filename quoting
issue).

>> * there is added "extended diff header", with <path> and <hash>
>>   hyperlinked (and <hash> shortened to 7 characters), and <mode>
>>   explained: '<mode>' is extended to '<mode> (<file type>)'.
>> * <file> hyperlinking should work also when <file> is originally
>>   quoted. For now we present filename quoted. This needed changes to
>>   parse_difftree_raw_line subroutine. And doesn't work: perhaps
>>   unquote is broken.
> 
> In which case we shouldn't commit this.  IOW, let's commit things
> which we _know_ to work.
> 
> Why not resubmit your original patch with the bugfixes as few comments
> as mentioned?

I'll do that, but for now quoting/unquoting filename is broken, both
in gitweb but also to lesser extent in git core (quoting perfectly valid
UTF-8 characters).

I'll try to adress that, but I wanted to send next RFC patch for review.

>> * from-file/to-file two-line header lines have slightly darker color
>>   than removed/added lines.
>> * chunk header has now delicate line above for easier finding chunk
>>   boundary, and top margin of 1px.
> 
> Wouldn't this be confusing with the other fine lines?
> I personally don't like this chunk separation.  Chunk separation
> already exists as is and we view it all the time elsewhere.

But not always the program displaying diff can display such line
separating chunks, for example on text terminal it can't.

But if you think that the dotted 1px #ffbbff line is too intrusive,
we can remove it (and perhaps increase vertical space a few pixels).
I'd like to have more opinions first.

BTW. you can easily override it in your CSS file.
 
> If you'd like to separate chunks, why not darken the background
> of the section of line the chunk header is printed at?  I.e.
> anything between the @@ including the @@.

I'd rather have this one in a separate commit (this needs changes
to format_diff_line, not only to git_patchset_body).

-- 
Jakub Narebski
Poland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]