suggestions for gitweb

suggestions for gitweb

[Michael Niedermayer]

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

Hi

As we are switching from svn to git, we also have to switch from viewvc to
gitweb (or similar) and so ive thought id submit a short list of things
ive noticed in gitweb which i belive could be improved ...

* 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
    ...

* The color of adjacent blame "hunks" is so similar that its
  indistinguishable on my notebook TFT when iam looking at it from slightly
  above

* 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 ...

* i either cant find the long history for a file or there is none ("history"
  is like "short log" and "log" is not file specific) a "long history" link
  in addition to "history" would be nice

* 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

* the history/log pages could contain some statistics for the commits like
  the number of files changed and lines added/removed

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle

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

Re: suggestions for gitweb

[Junio C Hamano]

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.

> * 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?

> * 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.

> * i either cant find the long history for a file or there is none ("history"
>   is like "short log" and "log" is not file specific) a "long history" link
>   in addition to "history" would be nice

Probably.

> * 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?

> * the history/log pages could contain some statistics for the commits like
>   the number of files changed and lines added/removed

Probably.

The three last items should be relatively easy, if somebody is
interested.  Pasky, Jakub, what do you think?

Re: suggestions for gitweb

[Aaron Gray]

>> * the history/log pages could contain some statistics for the commits 
>> like
>>   the number of files changed and lines added/removed
>
> Probably.
>
> The three last items should be relatively easy, if somebody is
> interested.  Pasky, Jakub, what do you think?

I would like to see lines of code and file sizes too.

Aaron

Re: suggestions for gitweb

[Michael Niedermayer]

[-- 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 --]

Re: suggestions for gitweb

[Jakub Narebski]

Aaron Gray wrote:

>>> * the history/log pages could contain some statistics for the commits 
>>>   like the number of files changed and lines added/removed
>>
>> Probably.
>>
>> The three last items should be relatively easy, if somebody is
>> interested.  Pasky, Jakub, what do you think?
> 
> I would like to see lines of code and file sizes too.

Diff statistics for difftree / whatchanged, or diff shortstat is a bit
costly, as it needs to generate and examine diff, and not only compare
trees. Besides --numstat doesn't support renames well now, but that
might not be an obstacle.

Lines of code and file sizes: file size needs additional invocation
per each file for gitweb; it would be easier for cgit. Costly! Counting
LOC is even more costly: take note that 1.) gitweb operates directly
on repository / object database, and does not use working area, 
2.) git is snapshot based and not changeset based.

Of course like in the case of other costly features this migh be enabled
at will using %feature hash...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: suggestions for gitweb

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Lines of code and file sizes: file size needs additional invocation
> per each file for gitweb; it would be easier for cgit. Costly! Counting
> LOC is even more costly: take note that 1.) gitweb operates directly
> on repository / object database, and does not use working area, 
> 2.) git is snapshot based and not changeset based.

We earlier discussed to make --numstat to allow us add this kind
of information for easier script consumption.

Perhaps instead of modifying --numstat, we may be better off to
add another format that can be more easily extended to support
other things, like we do for the --porcelain format out of
git-blame?  It does not have to be one line per record, like the
way --numstat was done, which was primarily in order to make it
a compact, human readable format.

Re: suggestions for gitweb

[Jakub Narebski]

On Sun, 13 May 2007, Michael Niedermayer wrote:
> 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, 
>>>   [...] 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 revision/date
>>>     tree        - directory at a specific revision/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 have misunderstand me :(
> I want to educate them, but I cannot as I am 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

Back in the times where there was no git homepage, the git logo at
top right corner of gitweb page was link to git documentation
  http://www.kernel.org/pub/software/scm/git/docs/
(with the title of "git documentation"), or to be more exact to HTML
version of git(7) man page. This page has link to git glossary, where
you can find explanation of this terms. Now it is link to git homepage;
I'm not sure where / if there is here link to git glossary.

It is very easy to change URL where git logo points to; either via
setting appropriate variables when running make to get gitweb.cgi out
of gitweb.perl, or via configuration file for gitweb. You can point
git logo to lead to your documentation of gitweb terms.

But gitweb was primarly meant for developers which works which git,
and have knowledge of git terms (and gitweb terms, as gitweb uses them).

Adding some gitweb-help.html page, linked somewhere from within gitweb
pages (I think it shouldn't be embedded in gitweb, like help for search
options is), certainly is possible. And perhaps we should do that, now
that gitweb is more widely deployed, and used by "accidental" users
(developers) with no knowledge of git, and perhaps even without
knowledge of SCM [terms].

By the way, I think only "blob" and perhaps "tree" terms really needs
explanation...


Sidenote: we used to have some links to 'blob_plain' action, which
returns exact contents of file at given revision to the browser
(trying to set appropriate mime type), named "plain" and some named
"raw". This ambiguity was resolved in favor of "raw". Is it better?
I'm not sure...

> [...]
>>> * 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 doesn't limit it to the blob ...

It should be fairly easy to add "diff to prev" link, but is it really
needed? It would be yet another link. Diff to previous version of blob
is contained in "commitdiff" and is easy to find and go to... well,
unless you are used to make large commits...

-- 
Jakub Narebski
Poland

Re: suggestions for gitweb

[Jakub Narebski]

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> Lines of code and file sizes: file size needs additional invocation
>> per each file for gitweb; it would be easier for cgit. Costly!
>> Counting LOC is even more costly: take note that 1.) gitweb operates
>> directly on repository / object database, and does not use working
>> area, 2.) git is snapshot based and not changeset based.
> 
> We earlier discussed to make --numstat to allow us add this kind
> of information for easier script consumption.
> 
> Perhaps instead of modifying --numstat, we may be better off to
> add another format that can be more easily extended to support
> other things, like we do for the --porcelain format out of
> git-blame?  It does not have to be one line per record, like the
> way --numstat was done, which was primarily in order to make it
> a compact, human readable format.

Even if we extend --numstat or add yet another diff format meant for
porcelain[*1*], and optionally add similar extension to git-ls-tree
(as I think object size and LOC of file should be placed there), and
the cost of additional fork and exec is not an issue, such extra 
information be still costly in terms of performance: CPU and I/O.

Currently for difftree (whatchanged-like) we need only to compare
trees. For lines added / lines removed statistics we need to _generate_ 
diff.

For file size (object size) we need at least find the object in question 
and read it's header; for lines of code we need to get blob contents
(find object, uncompress, optionally undeltify) and count the lines.

Its not insurmountable: we can use %feature for that, like in the case
of other CPU-intensive features like 'blame' or 'pickaxe', or 
high-bandwidth features like 'snapshot'.


Footnotes:
----------
[*1*] What we should name it? --numstat-extended, --machinestat,
--porcelain, --allstat, <insert your own idea here>?

-- 
Jakub Narebski
Poland

Re: suggestions for gitweb

[Lars Hjemli]

On 5/13/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Aaron Gray wrote:
>
> >>> * the history/log pages could contain some statistics for the commits
> >>>   like the number of files changed and lines added/removed
> >>
> >> Probably.
> >>
> >> The three last items should be relatively easy, if somebody is
> >> interested.  Pasky, Jakub, what do you think?
> >
> > I would like to see lines of code and file sizes too.
>
> Diff statistics for difftree / whatchanged, or diff shortstat is a bit
> costly, as it needs to generate and examine diff, and not only compare
> trees. Besides --numstat doesn't support renames well now, but that
> might not be an obstacle.
>
> Lines of code and file sizes: file size needs additional invocation
> per each file for gitweb; it would be easier for cgit. Costly! Counting
> LOC is even more costly

I've implemented number of files/lines changed in cgit's log view and
pushed it to http://hjemli.net/git/

It does consume some cpu (especially on the linux-2.6 repo), but it's
not terribly bad (and the caching helps out). But I felt like changing
the number of commits per page to 50, so I added a knob for this in
the config file while at it.

I'll try to get a proper diffstat on the commit page + file history
via tree view next (filesize has always been part of cgits tree view
btw).

--
larsh

Re: suggestions for gitweb

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Adding some gitweb-help.html page, linked somewhere from within gitweb
> pages (I think it shouldn't be embedded in gitweb, like help for search
> options is), certainly is possible. And perhaps we should do that, now
> that gitweb is more widely deployed, and used by "accidental" users
> (developers) with no knowledge of git, and perhaps even without
> knowledge of SCM [terms].

Yeah, that is definitely an improvement.

> It should be fairly easy to add "diff to prev" link, but is it really
> needed? It would be yet another link. Diff to previous version of blob
> is contained in "commitdiff" and is easy to find and go to... well,
> unless you are used to make large commits...

It would not be "yet another".  It feels kind of odd to get the
whole commitdiff from that page to begin with, when the user
already expressed that his attention is focused on that
particular path --- that is why he is in the History page to
begin with.

Re: suggestions for gitweb

[Petr Baudis]

  Hi,

On Sun, May 13, 2007 at 02:01:52AM CEST, Michael Niedermayer wrote:
> 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

  I seriously doubt the usefulness of this. Meaning of all the links except
maybe blob seems immediately obvious for me, even if I try to imagine
that I know nothing about Git; maybe I'm wrong here, I might try to do
an experiment. :-)

  But, even if that's the case, when a new user meets gitweb and looks
at the 'history' link, what do you think she will do? Start hunting the
page for some link to a glossary? I yet have to see a user like that :-)
- I will bet that she just clicks at the link and figures out what it is
about based on what happenned.

> > > * 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

This idea occurred to me, but so if a file is born from 20 commits in a
single day, you have no distinction between them. And if you throw time
in the mix too, it already becomes way too long; I'd argue that even
username-date already feels too long.

> [...]
> > > * 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 ...

I don't know if it's better to limit commitdiff or not; a compromise
approach would be not to limit it but to jump to the fragment concerning
the given blob.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

Re: suggestions for gitweb

[Michael Niedermayer]

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

Hi

On Mon, May 14, 2007 at 03:08:31AM +0200, Petr Baudis wrote:
>   Hi,
> 
> On Sun, May 13, 2007 at 02:01:52AM CEST, Michael Niedermayer wrote:
> > 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
> 
>   I seriously doubt the usefulness of this. Meaning of all the links except
> maybe blob seems immediately obvious for me, even if I try to imagine
> that I know nothing about Git; maybe I'm wrong here, I might try to do
> an experiment. :-)
> 
>   But, even if that's the case, when a new user meets gitweb and looks
> at the 'history' link, what do you think she will do? Start hunting the
> page for some link to a glossary? I yet have to see a user like that :-)
> - I will bet that she just clicks at the link and figures out what it is
> about based on what happenned.

i agree with you that she will click on 'history' and figure out what it is
but if she wants to see the contents of one of the files then i think
she will be confused and not know where to click, and a 'help' link which
would lead to a page which explains what 'blob' is at the top of the page
would solve that with less frustration than random clicking around
(renaming blob to file_content would work too but i guess i would be
 lynched for mere suggesting ...)

this of course is not really a problem for ffmpeg, we could easily change
"our" gitweb to contain a help link

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus

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

Re: suggestions for gitweb

[Petr Baudis]

On Mon, May 14, 2007 at 04:00:02AM CEST, Michael Niedermayer wrote:
> i agree with you that she will click on 'history' and figure out what it is
> but if she wants to see the contents of one of the files then i think
> she will be confused and not know where to click,

I think she will just click on the filename - straightforward enough...?

> and a 'help' link which
> would lead to a page which explains what 'blob' is at the top of the page
> would solve that with less frustration than random clicking around
> (renaming blob to file_content would work too but i guess i would be
>  lynched for mere suggesting ...)

:-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

Suggestions for cgit (was: Re: suggestions for gitweb)

[Jakub Narebski]

On Sun, 13 May 2007, Lars Hjemli <hjemli@gmail.com> wrote:

> I've implemented number of files/lines changed in cgit's log view and
> pushed it to http://hjemli.net/git/
> 
> It does consume some cpu (especially on the linux-2.6 repo), but it's
> not terribly bad (and the caching helps out). But I felt like changing
> the number of commits per page to 50, so I added a knob for this in
> the config file while at it.
> 
> I'll try to get a proper diffstat on the commit page + file history
> via tree view next (filesize has always been part of cgits tree view
> btw).

What I lack in cgit is using git diff and showing extended diff headers
(and the ugly tight box around diff doesn't help either), and gitweb's
'commitdiff' view / git's git-show / git's git-format-patch.

I don't think displaying filesize slows cgit much (you need to find and
read object header for that, as this information is not present in a
tree object...

By the way, what do you think about http://git.or.cz/gitwiki/Gitweb 
page?
-- 
Jakub Narebski
Poland

Re: Suggestions for cgit (was: Re: suggestions for gitweb)

[Lars Hjemli]

On 5/14/07, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 13 May 2007, Lars Hjemli <hjemli@gmail.com> wrote:
>
> > I've implemented number of files/lines changed in cgit's log view and
> > pushed it to http://hjemli.net/git/
> >
> > It does consume some cpu (especially on the linux-2.6 repo), but it's
> > not terribly bad (and the caching helps out). But I felt like changing
> > the number of commits per page to 50, so I added a knob for this in
> > the config file while at it.
> >
> > I'll try to get a proper diffstat on the commit page + file history
> > via tree view next (filesize has always been part of cgits tree view
> > btw).
>
> What I lack in cgit is using git diff and showing extended diff headers
> (and the ugly tight box around diff doesn't help either), and gitweb's
> 'commitdiff' view / git's git-show / git's git-format-patch.

Yes, this has been lacking. Last night I pushed initial support for
'commitdiff', but it doesn't show git's extended diff headers, nor is
there any plain/patch view (but the ugly tiny box is still there, I'm
lousy at web design :)

That said, extended headers/patch view should be trivial to support so
I'll look into it.


> I don't think displaying filesize slows cgit much (you need to find and
> read object header for that, as this information is not present in a
> tree object...

True, I do

  type = sha1_object_info(sha1, &size)

per entry in tree view to get the size. It's fast.


> By the way, what do you think about http://git.or.cz/gitwiki/Gitweb
> page?

Nice, I hadn't noticed this page, maybe cgit should get one too? Well,
it probably should get some users first (are there anyone besides
myself?)

-- 
larsh

Re: suggestions for gitweb

[Michael Niedermayer]

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

Hi

On Mon, May 14, 2007 at 04:36:09AM +0200, Petr Baudis wrote:
> On Mon, May 14, 2007 at 04:00:02AM CEST, Michael Niedermayer wrote:
> > i agree with you that she will click on 'history' and figure out what it is
> > but if she wants to see the contents of one of the files then i think
> > she will be confused and not know where to click,
> 
> I think she will just click on the filename - straightforward enough...?

yes and no :)
i see 2 possible problems with this
first if she starts from the summary page (which is from where she would
start from if she clicked on 'ffmpeg') then she would see the recent 
history but no directory/file names, she would have to click on 'tree' 
here

the second possible problem i see is that while directory names are
displayed in iceweasel in underlined blue like links, filenames are
not, so she might not realize that she can click on them

another thing i just realized is that the blob/tree links on the tree
page seems redundant as the directory/file names already link to these
pages, iam just mentioning that as some people in this thread seemed to
like minimizing the number of links and the length of varous displayed
items

also file size and last modified dates would be interresting on the tree
page
viewvc displays on its equivalent page, time since last change
svn revission of the last change, the author/commiter of the last change
and the corresponding abbreviated log entry

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle

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

Re: suggestions for gitweb

[Petr Baudis]

  Hi,

On Mon, May 14, 2007 at 10:53:15AM CEST, Michael Niedermayer wrote:
> On Mon, May 14, 2007 at 04:36:09AM +0200, Petr Baudis wrote:
> > On Mon, May 14, 2007 at 04:00:02AM CEST, Michael Niedermayer wrote:
> > > i agree with you that she will click on 'history' and figure out what it is
> > > but if she wants to see the contents of one of the files then i think
> > > she will be confused and not know where to click,
> > 
> > I think she will just click on the filename - straightforward enough...?
> 
> yes and no :)
> i see 2 possible problems with this
> first if she starts from the summary page (which is from where she would
> start from if she clicked on 'ffmpeg') then she would see the recent 
> history but no directory/file names, she would have to click on 'tree' 
> here

  well, I guess our opinions on how hard it is to guess it through just
differ... :-)

> also file size and last modified dates would be interresting on the tree
> page
> viewvc displays on its equivalent page, time since last change
> svn revission of the last change, the author/commiter of the last change
> and the corresponding abbreviated log entry

  I guess this is much easier to retrieve in svn than in git - you
actually have to walk all the history to figure out this information as
there's no global per-file info; so this is very troublesome
performance-wise. I think there were some patches on the mailinglist
that dit this, though I'm not sure. Might be reasonable to cache this
(and git history properties make it possible to nicely make a very
easily reusable cache for this information).

  About file sizes, that also has some extra performance hit, but in
this case I suspect that it would be totally negligible (if implemented
at the plumbing level) - and I admit that I would like to see file sizes
too, they can help orientation in a foreign source tree a lot.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

Re: suggestions for gitweb

[Jakub Narebski]

On Mon, 14 May 2007, Petr Baudis <pasky@suse.cz> wrote:
> On Mon, May 14, 2007 at 10:53:15AM CEST, Michael Niedermayer wrote:

>> also file size and last modified dates would be interresting on the tree
>> page
>> viewvc displays on its equivalent page, time since last change
>> svn revission of the last change, the author/commiter of the last change
>> and the corresponding abbreviated log entry
> 
>   I guess this is much easier to retrieve in svn than in git - you
> actually have to walk all the history to figure out this information as
> there's no global per-file info; so this is very troublesome
> performance-wise. I think there were some patches on the mailinglist
> that dit this, though I'm not sure. Might be reasonable to cache this
> (and git history properties make it possible to nicely make a very
> easily reusable cache for this information).

I have sent some implementations of tree_blame, without any core
support, directly in Perl (in gitweb), just like early versions of
git-annotate. It did suck performance-wise quite a bit. You can find
it in 'gitweb/tree_blame' branch in my git repository at repo.or.cz

  http://repo.or.cz/w/git/jnareb-git.git?a=shortlog;h=gitweb/tree_blame

I think it would be nice to have --blame option to git-ls-tree 
(optionally copuled with --porcelain and perhaps --incremental, like
in git-blame), which would return blame information for tree entries.
It means that for each tree entry return commit closest to given commit
(or furthest from a given commit) which has changed entry to current
version. It should be much easier and faster than to do "blob"-blame.

The --porcelain would also return 'last changed' info, like committer
info for a commit-which-changed.

But is this info actually interesting, or is it there in ViewVC because
it is easy to get this info in CVS and Subversion? The "last changed"
info for tree entries encourages to think of a history as a collection
of per file histories... while git is all about whole project history.
Note that history of two files is *more* than concatenation of
histories of those individual files. See entries on GitFaq wiki page:
 
>   About file sizes, that also has some extra performance hit, but in
> this case I suspect that it would be totally negligible (if implemented
> at the plumbing level) - and I admit that I would like to see file sizes
> too, they can help orientation in a foreign source tree a lot.

It should be very easy to add --long / --sizes option to git-ls-tree
which would return file sizes, perhaps after mode info.

-- 
Jakub Narebski
ShadeHawk on #git
Poland

Re: suggestions for gitweb

[Michael Niedermayer]

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

Hi

On Mon, May 14, 2007 at 06:49:35PM +0200, Jakub Narebski wrote:
[...]
> I think it would be nice to have --blame option to git-ls-tree 
> (optionally copuled with --porcelain and perhaps --incremental, like
> in git-blame), which would return blame information for tree entries.
> It means that for each tree entry return commit closest to given commit
> (or furthest from a given commit) which has changed entry to current
> version. It should be much easier and faster than to do "blob"-blame.
> 
> The --porcelain would also return 'last changed' info, like committer
> info for a commit-which-changed.
> 
> But is this info actually interesting, or is it there in ViewVC because
> it is easy to get this info in CVS and Subversion? The "last changed"
> info for tree entries encourages to think of a history as a collection
> of per file histories... while git is all about whole project history.
> Note that history of two files is *more* than concatenation of
> histories of those individual files. See entries on GitFaq wiki page:

well, i do think that the age can be interesting, consider the 2
hypothetical cases:
'release_notes.txt 5 years ago' while all other files have been recently
changed
clearly says: noone cares about this file or there was no release in 
the last 5 years

also for example
'vo_x11.c    2 days ago  michael     update all vos to use correct foobar'
'vo_mga.c    8 weeks ago diego       spelling fixes'
would immedeatly hint that ive forgotten vo_mga.c ...

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch

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

Re: Suggestions for cgit (was: Re: suggestions for gitweb)

[Lars Hjemli]

On 5/14/07, Lars Hjemli <hjemli@gmail.com> wrote:
> On 5/14/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Sun, 13 May 2007, Lars Hjemli <hjemli@gmail.com> wrote:
> >
> > > I've implemented number of files/lines changed in cgit's log view and
> > > pushed it to http://hjemli.net/git/
> > >
> > > It does consume some cpu (especially on the linux-2.6 repo), but it's
> > > not terribly bad (and the caching helps out). But I felt like changing
> > > the number of commits per page to 50, so I added a knob for this in
> > > the config file while at it.
> > >
> > > I'll try to get a proper diffstat on the commit page + file history
> > > via tree view next (filesize has always been part of cgits tree view
> > > btw).
> >
> > What I lack in cgit is using git diff and showing extended diff headers
> > (and the ugly tight box around diff doesn't help either), and gitweb's
> > 'commitdiff' view / git's git-show / git's git-format-patch.
>
> Yes, this has been lacking. Last night I pushed initial support for
> 'commitdiff', but it doesn't show git's extended diff headers, nor is
> there any plain/patch view (but the ugly tiny box is still there, I'm
> lousy at web design :)
>
> That said, extended headers/patch view should be trivial to support so
> I'll look into it.

Ok, the ugly box is gone and 'commit-diff' now looks more like 'git
show'. Thanks for the suggestion.

--
larsh

Re: suggestions for gitweb

[Jan Hudec]

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

Hello,

On Mon, May 14, 2007 at 04:00:02 +0200, Michael Niedermayer wrote:
> On Mon, May 14, 2007 at 03:08:31AM +0200, Petr Baudis wrote:
> >   But, even if that's the case, when a new user meets gitweb and looks
> > at the 'history' link, what do you think she will do? Start hunting the
> > page for some link to a glossary? I yet have to see a user like that :-)
> > - I will bet that she just clicks at the link and figures out what it is
> > about based on what happenned.
> 
> i agree with you that she will click on 'history' and figure out what it is
> but if she wants to see the contents of one of the files then i think

Well, before clicking it, she will move the mouse pointer over it. And either
look for tooltip -- which sadly won't come up -- or read the url -- with
sadly isn't much help.

> she will be confused and not know where to click, and a 'help' link which
> would lead to a page which explains what 'blob' is at the top of the page
> would solve that with less frustration than random clicking around

IMHO providing tooltips would probably solve it with even less frustration.
If the user comes to the page, she will probably quickly notice, that the
links have tooltips. And than going over all the links with the pointer and
reading the tooltips is a lot easier and faster than switching to a help
page. Besides people don't want to admit, even to themselves, they don't
understand something to a point they should read the docs, so they won't read
it. But anybody will read the tooltips -- they don't look like docs.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

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