Re: [PATCH/RFC] gitweb: New improved patchset view

From: Luben Tuikov <ltuikov@yahoo.com>
Date: Oct 30, 2006, 01:43 UTC
Message-ID: <811156.54327.qm@web31808.mail.mud.yahoo.com>
In-Reply-To: <7v3b972bzq.fsf@assigned-by-dhcp.cox.net>

--- Junio C Hamano <junkio@cox.net> wrote:

Show 13 quoted lines

> Before answering 3 questions, I think we need to ask a bigger
> question.  What is the primary target audience of gitweb?
> 
> If it is for git-uninitiated, then staying as close to what GNU
> diff would give would be a better idea.  I would say we at least
> can assume that the user has some familiarity with SCM, and
> knows what kind of information is kept track of and is shown as
> differences between versions, and what files, directories and
> symlinks are, but not how git represents these.  On the other
> hand, if the user uses git to track a project (not necessarily
> the project the user is looking at with gitweb) and is familiar
> with the way git-diff presents these information, deviating from
> git-diff output is distractiing.

I agree.

gitweb's primary audience is the developers who type "git ..." at shell prompt all the time.

> At least to me /-rw-rw-... part made me feel uneasy for that
> reason.

It made me feel uneasy to see it where it was because it didn't belong there either way.

Show 7 quoted lines

> WIth that in mind, I'll think aloud what I would like if I were
> not familiar with git:
> 
>  * "diff --git a/file b/file" would not use /dev/null but
>    ---/+++ does.  If the former is shown as link, it should be
>    visible which side is a link and which side is not for
>    creation or deletion diff; otherwise you would need a second

I'd argue otherwise: trying to click on /dev/null and failing but succeeding on b/file has already taught something to the uinitiated user.

OTOH, if one is trying to "click" on /dev/null in gitweb commitdiff view -- they have other problems to resolve first...

Show 5 quoted lines

>    to realize it is not a bug that clicking on a/file on the
>    "diff --git" line did not show anything for a creation diff.
> 
>  * I think showing object names in "index xxx..yyy mode" line is
>    not very useful to humans (they are added for tools).  I do

I like to see it because I might need to know the sha in order to go back to shell prompt and do something with the object. Instead of having to git-ls-tree -r .... in order to find it from the sha of the commitdiff.

>    agree that we would want some clickable handle in combined
>    diff output, but people not familiar with git would not know
>    that "index xxx,yyy..zzz" is where you would find the
>    parents, so that line needs to be munged anyway.

I think gitweb should first and foremost cater to git users.

>    Side note: Even though some git people (Luben, for example)
>    claim they recognize some abbreviated object names, I suspect
>    that are mostly recent commits and not blobs.

Yes, commit-8 for the day, blob-8 for less than a minute which allows me to move the mouse pointer from to the xterm.

Show 6 quoted lines

>  * Mode on the "index" line may be useful, but as you say 100644
>    is probably too git specific; however if our audience is
>    git-uninitiated, I doubt -rw-r--r-- is much better (it is
>    UNIXism, which I personally do not mind).  Spelling them out
>    like "regular file", "executable file", or "symbolic link"
>    might be more readable.

It would be more readable, but then it would be more readable. Ideally I'd like it to be less readable, i.e. less to read.

>  * I think the filename quoting is better left as-is, since it
>    is a way to indicate something funny is going on.

I agree.

   Luben