RFC patch, 4 partsgitweb: ViewVC-like "tree_blame" view

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

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 <jnareb@gmail.com> writes:

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.

Junio C Hamano wrote:

Good idea.

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

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.

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.

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

On Thursday 31 August 2006 02:18, Jakub Narebski wrote:

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

Josef Weidendorfer wrote:

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 wrote:

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.

Hello,

thanks, I bounced the messages to him.

        Thomas

Thomas Glanzmann wrote:

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.