--- Junio C Hamano <junkio@xxxxxxx> wrote: > Luben Tuikov <ltuikov@xxxxxxxxx> writes: > > > --- Junio C Hamano <junkio@xxxxxxx> wrote: > >> Luben Tuikov <ltuikov@xxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html