All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.