git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Niedermayer <michaelni@gmx.at>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org, Jakub Narebski <jnareb@gmail.com>,
	Petr Baudis <pasky@ucw.cz>
Subject: Re: suggestions for gitweb
Date: Sun, 13 May 2007 02:01:52 +0200	[thread overview]
Message-ID: <20070513000151.GT14859@MichaelsNB> (raw)
In-Reply-To: <7v8xbtwtsy.fsf@assigned-by-dhcp.cox.net>

[-- Attachment #1: Type: text/plain, Size: 3409 bytes --]

Hi

On Sat, May 12, 2007 at 03:39:25PM -0700, Junio C Hamano wrote:
> Michael Niedermayer <michaelni@gmx.at> writes:
> 
> > * gitweb uses many terms which are new to a non git user, and while
> >   devlopers who work on ffmpeg will very likely very quickly have
> >   figured out the meaning of all of them. i think simple users who just
> >   want to browse the ffmpeg code will have their problems, so i belive 
> >   a small help text linked to from all pages which contains a short
> >   definition of all the git(web) specific terms would be very helpfull
> >   something like
> >     blob        - file      at a specific revission/date
> >     tree        - directory at a specific revission/date
> >     (short) log - project wide commit log
> >     history     - short log equivalent for a file or directory
> 
> Coming fron non-CVS camp, I think changing this to non-git terms
> is very harmful than educating users who are migrating from
> other systems.

you must missunderstand me :(
i want to educate them, but i cannot as iam not speaking about ffmpeg
developers/contributors but rather random people who are curious and 
want to take a look at the ffmpeg source

for them a simple help link similar to "ViewVC Help" which viewvc has
on the bottom right of its pages would be great IMHO
also the text above is a pure random suggestion by a svn user and was
not intended to redefine any git terms


> 
> > * The color of adjacent blame "hunks" is so similar that its
> >   indistinguishable on my notebook TFT when iam looking at it from slightly
> >   above
> 
> This is more or less intentional to make the difference not too
> distracting.  I thought it was controlled via css which
> something you can use browser side tricks to suite your taste?

i sure can, i just thought the default was less than optimal


> 
> > * The blame page shows the SHA1 for each hunk and IMHO thats the last thing
> >   i would want to see first, id be much more interrested in by whom and
> >   when a given change was done, iam wondering in which case the SHA1 would
> >   be usefull? copy-paste onto your command line git tools but then why
> >   use gitweb at all, 'git blame' would make more sense IMHO and a simple
> >   click would reveal the sha1 with more info anyway ...
> 
> They serve no purpose other than showing something to click on,
> and allow you to hover over (some people argued in the past
> that they recognize certain commit object names, but honestly I
> would not believe them).  However, I do not think there are much
> better alternatives.  Try coming up with a different "label"
> string that is of uniform length across commits, and does not
> chew up too much screen real estate.

trivial
the first N chars of the username + YYMMDD

so for example:
michaeln070612

or with space:
michaeln 070612


[...]
> > * on the history page there are "blob", "commitdiff" and "diff to current"
> >   the obvious missing one is "diff to previous" which would be the diff to
> >   the previous blob of this file
> 
> Isn't that commitdiff, or commitdiff on that page does not limit
> the diff to the blob?

commitdiff doesnt limit it to the blob ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2007-05-13  0:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-12 20:55 suggestions for gitweb Michael Niedermayer
2007-05-12 22:39 ` Junio C Hamano
2007-05-12 23:15   ` Aaron Gray
2007-05-13  0:41     ` Jakub Narebski
2007-05-13  0:54       ` Junio C Hamano
2007-05-13 11:50         ` Jakub Narebski
2007-05-13 16:52       ` Lars Hjemli
2007-05-14  7:31         ` Suggestions for cgit (was: Re: suggestions for gitweb) Jakub Narebski
2007-05-14  8:50           ` Lars Hjemli
2007-05-15 12:57             ` Lars Hjemli
2007-05-13  0:01   ` Michael Niedermayer [this message]
2007-05-13 11:18     ` suggestions for gitweb Jakub Narebski
2007-05-14  0:28       ` Junio C Hamano
2007-05-14  1:08     ` Petr Baudis
2007-05-14  2:00       ` Michael Niedermayer
2007-05-14  2:36         ` Petr Baudis
2007-05-14  8:53           ` Michael Niedermayer
2007-05-14  9:58             ` Petr Baudis
2007-05-14 16:49               ` Jakub Narebski
2007-05-14 17:37                 ` Michael Niedermayer
2007-05-15 15:46         ` Jan Hudec

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=20070513000151.GT14859@MichaelsNB \
    --to=michaelni@gmx.at \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=junkio@cox.net \
    --cc=pasky@ucw.cz \
    /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).