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.
'I guess people's eyes and brains are trained by the old school "file
boundaries matter" way of thinking'
-- Junio C Hamano
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.)
thank you all for your time, it was a real pleasure for me,
2013/1/14 Jeff King <p...@peff.net>:
> On Sun, Jan 13, 2013 at 11:08:32PM -0800, Jonathan Nieder wrote:
>> Jeff King wrote:
>> > 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
> I'd rather finish cleaning it up and actually get it merged. It's on my
> todo list.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html