Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jeff King <peff@xxxxxxxx> writes: > > But that still doesn't address the issue that (a) is not > > well-defined. Imagine I have this history: > > > > A--B--C---G--H > > \ / > > D--E--F > > > > that is, two lines of development splitting at A and merging > > at H. And imagine the commit timestamps are (let's just refer > > to them as integers for the sake of simplicity, but they are > > representing days or seconds or whatever): > > > > A(1)--B(2)--C(3)--G(7)--H(8) > > \ / > > D(2)--E(4)--F(6) > > > > What does it mean to ask for the commit at time=5? > > ... > > Git-blame expects you to give it a well-defined point ... > > You could do so by asking rev-list to walk the graph according > > to your requirements and feeding the result to blame, like: > > > > # most recent on any line of development that is merged to HEAD > > git blame `git rev-list -1 --until=5 HEAD` > > > > # most recent on any line of development in the whole repo > > git blame `git rev-list -1 --until=5 --all` > > > > # most recent version on the first-parent; if you follow a > > # topic-branch workflow and always merge up into "master", > > # then this will blame what was on master at time=5 > > git blame `git rev-list -1 --until=5 --first-parent HEAD` > > Very well explained. Thanks. +1 > The short answer to the question on "Subject:" line is "You don't". The slightly longer, but perhaps more practically useful, answer is "You use 'git rev-list' to look up the correct commit, and shell 'command substitution' to pass the result to 'git blame', as Jeff has illustrated." That solution sure beats displaying the entire revision list, and then manually selecting the desired commit from it. -- 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