git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH/RFC] gitweb: New improved patchset view
Date: Sun, 29 Oct 2006 13:24:42 +0100	[thread overview]
Message-ID: <200610291324.42566.jnareb@gmail.com> (raw)
In-Reply-To: <7viri34a3k.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> 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 link
>>   and uses default link style is changed to
>>     diff --git a/<file before> b/<file after>
>>   where <file> is hidden link (i.e. underline on hover, only)
>>   to appropriate version of file. If file is added, a/<file> is not
>>   hyperlinked, if file is deleted, b/<file> is not hyperlinked.
> 
> I do not have time to look at the code right now, but here are 
> quick comments on the output.

Code is a bit horrible I think in trying to be smart and avoid
code repetition.

> I personally do not mind "hidden" but it might be more obvious
> to make them normal links -- the filenames in the header are not
> part of long text people need to "read".  On the other hand,
> it feels a bit wasteful to have these hidden links both on "diff
> --git" line *and* ---/+++ lines (these three are very close to
> each other).

Good idea. We have lost visible links with the change. And easy to
implement: just remove style override for .diff.header a.list from
CSS (or what would be better but harder to code remove "list" class
from <a> element in "git header").

Originally there was visible link with full sha1 of blob as text,
and hidden link with filename as text; perhaps dropping the latter
---/+++ line link is better idea (here hyperlink should I think be
hidden, if there is any, to match git-diff and GNU diff -u output).
And this would simplify code somewhat...

The hidden (but here I think we can change to not-hidden links) links
in the "index" extended header line are to stay I think: this is the
only place where we can have links to all the versions of file in the
future combined commitdiff format.

>> * there is added "extended diff header", with <path> and <hash>
>>   hyperlinked (and <hash> shortened to 7 characters), and <mode>
>>   explained: '<mode>' is extnded to '<mode>/<symbolic mode> (<file type>)'.
> 
> It somehow feels that deviating from what "git diff" gives makes
> it very distracting; I would feel better if "/-rw-r--r-- (file)"
> were not there.

Well, the old version had "(<file type>)" in gitweb diff header.
Not all git/gitweb users are familiar with POSIX numeric modes;
perhaps changing the style (color for example) of added stuff
to mark it as added would be enough?

> Also I think arguing over 7 or 8 hexdigits is pointless; if you
> are reading this from "git diff", it is probably the easiest to
> match what "git diff" gave you.  One thing we _might_ want to do
> in the future is to change "git diff" to use DEFAULT_ABBREV
> hexdigits at the minimum but more if needed to disambiguate; I
> think it currently does not do the "more if needed" part.

I used 7 hexdigits because git-diff uses 7 by default.

>> * <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.
> 
> This feels Ok.

I'm not sure if we shouldn't unquote filename always, or at least
remove double quotes surrounding filename, or [ab]/filename. The decision
to leave visible filename quoted was based on the troubles to code
it correctly in "git diff" header where one of the filenames might
not be hyperlinked: if file was added or deleted.

>> * from-file/to-file two-line header lines have slightly darker color
>>   than removed/added lines.
> 
> This visually feels right.

What is left is fine-tuning the color.

>> * chunk header has now delicate line above for easier finding chunk
>>   boundary, and top margin of 1px.
> 
> This visually feels right.

What is left is fine-tuning the line and vertical space.
-- 
Jakub Narebski

  reply	other threads:[~2006-10-29 12:24 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-29 10:22 [PATCH/RFC] gitweb: New improved patchset view Jakub Narebski
2006-10-29 11:47 ` Junio C Hamano
2006-10-29 12:24   ` Jakub Narebski [this message]
2006-10-29 12:48     ` Jakub Narebski
2006-10-29 15:35   ` Jakub Narebski
2006-10-29 19:43     ` Luben Tuikov
2006-10-29 20:19       ` Jakub Narebski
2006-10-29 22:05         ` Jakub Narebski
2006-10-29 20:29       ` Junio C Hamano
2006-10-29 19:33   ` Luben Tuikov
2006-10-29 12:44 ` Anand Kumria
2006-10-29 19:38   ` Luben Tuikov
2006-10-29 17:50 ` Jakub Narebski
2006-10-29 18:49   ` Junio C Hamano
2006-10-30  1:43     ` Luben Tuikov
2006-10-29 19:55   ` Luben Tuikov
2006-10-29 20:29     ` Jakub Narebski
2006-10-29 19:31 ` Luben Tuikov
2006-10-29 23:51 ` [PATCH/RFC (take 2)] " Jakub Narebski
2006-10-30  0:34   ` Jakub Narebski
2006-10-30  1:12     ` Junio C Hamano
2006-10-30  1:21       ` Jakub Narebski
2006-10-30  1:59   ` Luben Tuikov
2006-10-30  8:05     ` Jakub Narebski
2006-10-30  8:21       ` Junio C Hamano
2006-10-30  8:51         ` Junio C Hamano
2006-10-30  9:43         ` Jakub Narebski
2006-10-30 13:58           ` Jakub Narebski
2006-10-30 22:59             ` Junio C Hamano
2006-10-30 23:32               ` Jakub Narebski
2006-10-30 23:40                 ` Junio C Hamano
2006-10-30 21:34       ` Luben Tuikov
2006-10-30 21:50         ` Jakub Narebski
2006-10-30 22:30           ` Edgar Toernig
2006-10-30 22:39             ` Jakub Narebski
2006-10-31 22:41               ` Edgar Toernig
2006-10-30 22:40           ` Luben Tuikov
2006-10-30 23:00             ` Junio C Hamano
     [not found] <200610290100.11731.jnareb@gmail.com>
2006-10-28 23:16 ` [PATCH/RFC] " Jakub Narebski
2006-10-29 10:59   ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200610291324.42566.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).