Re: git list files

I went through your initial thread about blame-tree,
and it is really very very (+very) close to answer my question.

Thanks for writing it,
if it comes one day to git, I will use it.

As for:
'I guess people's eyes and brains are trained by the old school "file
boundaries matter" way of thinking'
-- Junio C Hamano
at http://thread.gmane.org/gmane.comp.version-control.git/168323;
http://article.gmane.org/gmane.comp.version-control.git/168333

I think it's not the case, Mr. Hamano.

From my point of view, it is just to have a quick picture of "what

came from where in this current directory",
which is a normal reaction of human beings, I think.

Speaking of which I can't help thinking that this feature could be
provided by $git rev-list (HEAD) --no-walk -- <paths>, just don't stop
at first commit,
but at first commit for each of the paths.

Or maybe diff could have an option to not compare against a specific point,
but actually do his job and go downstears and find where the
_diff_erence for _each_ path happened finally.

(... applicable for $git status -l (--list) --porcelain ... but thats
a whim, sorry.)

Anyway,
thank you all for your time, it was a real pleasure for me,
Blind.

2013/1/14 Jeff King [off-list ref]:

On Sun, Jan 13, 2013 at 11:08:32PM -0800, Jonathan Nieder wrote:

quoted

Jeff King wrote:

quoted

As far as I recall, that script works. However, I have a pure-C
blame-tree implementation that is much faster, which may also be of
interest. I need to clean up and put a few finishing touches on it to
send it to the list, but it has been in production at GitHub for a few
months. You can find it here:

  git://github.com/peff/git jk/blame-tree

Oh, neat.  Would that make sense as an item in
<https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools>?

I'd rather finish cleaning it up and actually get it merged. It's on my
todo list.

-Peff