[PATCH/RFC 0/4] gitweb: ViewVC-like "tree_blame" view

[PATCH/RFC 0/4] gitweb: ViewVC-like "tree_blame" view

[Jakub Narebski]

In response to Thomas Glanzmann (or rather a friend of his) request, 
here is series of patches which adds to tree view information about 
when last time and by whom was given file or directory touched.  As git 
records "snapshot history" and commits are whole tree, and not have per 
file history, it means that one wants to know last commit counting from 
the top which has the same version of file or the same tree.  This is 
something similar to blame (aka. annotate) for file, hence naming such 
view "tree_blame".

Current implementation is done inefficiently directly in gitweb, and 
serves rather as a proof of concept than as a serious implementation to 
use.

This series of patches is based on 'next' (v1.4.2-g39ee2f6) equivalent, 
but with the commit 25691fbe6d02135d55dfc3a5180e29890dce1521
   gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'}
reverted, as it needs git version post v1.4.2-rc2, while I use git 
version 1.4.1.1, as there are no i386 RPMS for 1.4.2 yet.

ViewCVS/ViewVC prints the last touch of a a file in a directory and you 
can tell it to sort after the date criteria:
http://faumachine.informatik.uni-erlangen.de/cgi-bin/viewcvs.cgi/mutt/?sortby=date#dirlist

-- 
Jakub Narebski
ShadeHawk on #git
Poland

Re: [PATCH/RFC 0/4] gitweb: ViewVC-like "tree_blame" view

[Jakub Narebski]

At the below URL (links of course _won't_ work)
  http://front.fuw.edu.pl/jnareb/tree_blame.html
is output of  "tree_blame" view. One can sort by Date (age), Author, Mode
and Filename. The date view was modelled after 'ls -l' view; the order of
columns probably should be changed to match it more closely.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH/RFC 0/4] gitweb: ViewVC-like "tree_blame" view

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> At the below URL (links of course _won't_ work)
>   http://front.fuw.edu.pl/jnareb/tree_blame.html
> is output of  "tree_blame" view. One can sort by Date (age), Author, Mode
> and Filename. The date view was modelled after 'ls -l' view; the order of
> columns probably should be changed to match it more closely.

Just a quick impression.

 - "Mode" looks too wide for the information it conveys.  Path
   being a link already tells whether it is a tree, so the only
   information you would need is a bit and half (regular file,
   executable regular file, or symbolic link).

 - Spelling out Date in human readable form is fine but I suspect
   it would be nicer if it used YYYY-MM-DD / MM-DD HH:MM

 - I personally do not like blaming the last person who touched
   the file, but that is probably just me so it is fine.

 - "Commit" column does not seem to convey much useful
   information; I would suggest perhaps making Date and/or
   Author clickable to take the browser to the commit, but I do
   not understand what the strike-through is about...

 - Since the rightmost links have quite a lot of information
   these days, it _might_ be reasonable to make the main part
   2 lines, like so:

	date    author   mode    path
        short-commit-log-message

	date    author   mode    path
        short-commit-log-message

        ...

 - I wonder how expensive it is to generate this.

Re: [PATCH/RFC 0/4] gitweb: ViewVC-like "tree_blame" view

[Jakub Narebski]

Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> At the below URL (links of course _won't_ work)
>>   http://front.fuw.edu.pl/jnareb/tree_blame.html
>> is output of  "tree_blame" view. One can sort by Date (age), Author, Mode
>> and Filename. The date view was modelled after 'ls -l' view; the order of
>> columns probably should be changed to match it more closely.
> 
> Just a quick impression.
> 
>  - "Mode" looks too wide for the information it conveys.  Path
>    being a link already tells whether it is a tree, so the only
>    information you would need is a bit and half (regular file,
>    executable regular file, or symbolic link).
> 
>  - Spelling out Date in human readable form is fine but I suspect
>    it would be nicer if it used YYYY-MM-DD / MM-DD HH:MM

Good idea.

>  - I personally do not like blaming the last person who touched
>    the file, but that is probably just me so it is fine.

I was going for something similar to the 'ls -l' look, with symbolic mode,
user ("blame" i.e. last person who touched the file for gitweb), date in
'ls -l' format but in UTC and in C locale, file name. Preceded by commit,
followed by related links (tree/blob, blame, history, raw).

>  - "Commit" column does not seem to convey much useful
>    information; I would suggest perhaps making Date and/or
>    Author clickable to take the browser to the commit, but I do
>    not understand what the strike-through is about...

Ooops, I forgot to explain this. Strike-through, which actually should be
using different color like red for example means that the file has 1-commit
long history, i.e. it just appeared in given commit.

BTW. commit link should show commit title on mouseover.

>  - Since the rightmost links have quite a lot of information
>    these days, it _might_ be reasonable to make the main part
>    2 lines, like so:
> 
>       date    author   mode    path
>         short-commit-log-message
> 
>       date    author   mode    path
>         short-commit-log-message
> 
>         ...

I'd rather have 1 line per entry, especially considering that one of key
features is ability to sort the "tree_blame" table by date.

>  - I wonder how expensive it is to generate this.

Quite expensive, especially for directories (trees) containing larger number
of files, but if I remember correctly not much longer than for example
summary or tags page. Speed is constrained by the forking, one per
file/tree in given directory, at least for now.

There are three implementations in git_tree_blame...

Of course the engine should be rewritten in C, made into git-blame-tree
(similar to git-blame).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH/RFC 0/4] gitweb: ViewVC-like "tree_blame" view

[Josef Weidendorfer]

On Thursday 31 August 2006 02:18, Jakub Narebski wrote:
> Ooops, I forgot to explain this. Strike-through, which actually should be
> using different color like red for example means that the file has 1-commit
> long history, i.e. it just appeared in given commit.

Seems useful. Perhaps better green. And red for...
(As you talk about "just appeared") What's about deleted files, similar
to attic in CVS? It could be quite useful to provide an alternate
tree-blame mode including deleted files; where the given commit
would specify the deletion.

Josef

Re: [PATCH/RFC 0/4] gitweb: ViewVC-like "tree_blame" view

[Jakub Narebski]

Josef Weidendorfer wrote:

> On Thursday 31 August 2006 02:18, Jakub Narebski wrote:
>> Ooops, I forgot to explain this. Strike-through, which actually should be
>> using different color like red for example means that the file has
>> 1-commit long history, i.e. it just appeared in given commit.
> 
> Seems useful. Perhaps better green. And red for...
> (As you talk about "just appeared") What's about deleted files, similar
> to attic in CVS? It could be quite useful to provide an alternate
> tree-blame mode including deleted files; where the given commit
> would specify the deletion.

Deletion, or renaming.

Actually the currently used implementation (2-items max length history for
each file) doesn't allow for that. The other two implementations (you can
choose other 2 implementations by changing 'rev-list' in "my $version =
shift || 'rev-list'" to 'diff-tree' or 'ls-tree') can do this. I think it
would be perhaps easiest with git-ls-tree, if git-ls-tree would acquire
--stdin option, similar to git-diff-tree...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH/RFC 0/4] gitweb: ViewVC-like "tree_blame" view

[Thomas Glanzmann]

Hello,

> In response to Thomas Glanzmann (or rather a friend of his) request,
> here is series of patches which adds to tree view information about
> when last time and by whom was given file or directory touched. 

thanks, I bounced the messages to him.

        Thomas

Re: [PATCH/RFC 0/4] gitweb: ViewVC-like "tree_blame" view

[Jakub Narebski]

Thomas Glanzmann wrote:


>> In response to Thomas Glanzmann (or rather a friend of his) request,
>> here is series of patches which adds to tree view information about
>> when last time and by whom was given file or directory touched. 
> 
> thanks, I bounced the messages to him.

Just to note: this is proof of concept. The final implementation should have
engine written in C, in "core git", like git-blame. Currently this is very
expensive, so I didn't made gitweb with tree_blame available...

BTW. my reply to the first message have link to "screenshot" (saved view of
page to HTML) of the output.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH/RFC 0/4] gitweb: ViewVC-like "tree_blame" view

[Jakub Narebski]

Jakub Narebski wrote:

> Josef Weidendorfer wrote:
> 
>> On Thursday 31 August 2006 02:18, Jakub Narebski wrote:
>>> Ooops, I forgot to explain this. Strike-through, which actually should
>>> be using different color like red for example means that the file has
>>> 1-commit long history, i.e. it just appeared in given commit.
>> 
>> Seems useful. Perhaps better green. And red for...
>> (As you talk about "just appeared") What's about deleted files, similar
>> to attic in CVS? It could be quite useful to provide an alternate
>> tree-blame mode including deleted files; where the given commit
>> would specify the deletion.
> 
> Deletion, or renaming.
> 
> Actually the currently used implementation (2-items max length history for
> each file) doesn't allow for that. The other two implementations (you can
> choose other 2 implementations by changing 'rev-list' in "my $version =
> shift || 'rev-list'" to 'diff-tree' or 'ls-tree') can do this. I think it
> would be perhaps easiest with git-ls-tree, if git-ls-tree would acquire
> --stdin option, similar to git-diff-tree...

Actually, unless you list only "accidental" deleted files, i.e. the ones
encountered during "blaming" all the files in given directory, you would
need to go all the way back to the root to be sure that all deleted or
renamed files are listed.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git