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 (as it must, since > it is a backwards walk down history showing what led to a particular set > of content; it wouldn't make sense to feed it multiple starting points). > 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. The short answer to the question on "Subject:" line is "You don't". -- 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