Re: [PATCH] git-pickaxe: blame rewritten.

[Luben Tuikov <ltuikov@yahoo.com>]

--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > --- Junio C Hamano <junkio@cox.net> wrote:
> >> Luben Tuikov <ltuikov@yahoo.com> writes:
> >> 
> >> > Junio, is it possible to also print the "previous" commit?
> >> > I mean, is it tenable to print the commit such that
> >> > a "git-diff C B -- A:file" will give a diff of the block of lines
> >> > we're looking at?
> >> 
> >> There is no single "previous" in general.  Which side of the
> >> merge would you take?
> >
> > The parent commit.
> 
> There is no single "the parent commit" in general.  Which side
> of the merge would you take?

Yes, I realise that...

I guess I'm trying to get to a successful implementation of
the intention of commit 65910395c08e3dc4be685a9a9f60adfa61c89aa5
(later reverted for a good reason).

It is ok if this is not possible.  After all, the absolutely
unambiguous way is blame->commit->blame->commit->..., etc,
due to multiple parenting.

> Also remeber, when we blame a line to a revision (unless we do
> not limit the blame with v2.6.18.. and --since=2.weeks which
> only git-pickaxe can do), the line is known to have been
> introduced by _that_ commit.

That is what we want.

(fully agree with your previous comment that we limit _after_
 placing blame on a commit...)

> If there were a corresponding line
> in "the parent commit" for that line, we would not have assigned
> the blame to the commit, but the blame would have been passed
> down to "the parent commit" already.

Indeed.

   Luben