perryh@pluto.rain.com writes:
How do I get "git blame" to operate "as of" a particular date in
the past, without having to manually look up the corresponding
SHA1 using "git rev-list"? For example, I can get a report as of
2011-12-29 by doing something like:
$ git rev-list --all --date-order --format="%h %ai" .
...
7c69106 2012-01-03 ...
b4227af 2011-12-27 ...
...
$ git blame <file> b4227af
but I want to have git look up the last revision prior to the given
date, by doing something like
$ git blame <file> @{2011-12-29}
You are looking at two different dates:
a) The dates stored within the commit object:
- committer date, similarly shown by %ci: when the commit was created.
- author date, shown by %ai: when "this" commit was "first created".
These are properties of the commits, and thus part of the project
history. Anyone who clones the project sees the same dates.
b) The dates in the reflog, tracking the movement of *your local* refs
(like the name implies). The HEAD reflog tracks what *you* had
"currently checked out" at a given time.
An automated search in (b) is possible with the @{} syntax, but note
that it tracks the *branch state*. It says nothing about how "current"
a certain resulting commit was. For example, if you say
git checkout v1.6.0
sleep 2
git checkout -
git show '@{1 second ago}'
you will see the commit for v1.6.0 from back in 2008.
An automated search in (a) is hard, mostly because in nonlinear history
there is not usually a single (and well-defined) commit that could be
returned. Git could attempt to search all of your branches, like you
have done above, but which one among all commits from that date should
it pick? Furthermore, the result set to pick from will change if you
fetch more history into your repo.
It's even worse with the author (as opposed to committer) dates: those
are not even remotely close to monotonic in most repos, because they are
kept across rewriting. (The committer dates would be monotonic if
everyone kept their clocks in sync and avoided filter-branch tricks.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
Thomas Rast [off-list ref] wrote:
perryh@pluto.rain.com writes:
quoted
How do I get "git blame" to operate "as of" a particular date in
the past, without having to manually look up the corresponding
SHA1 using "git rev-list"? For example, I can get a report as
of 2011-12-29 by doing something like:
$ git rev-list --all --date-order --format="%h %ai" .
...
7c69106 2012-01-03 ...
b4227af 2011-12-27 ...
...
$ git blame <file> b4227af
but I want to have git look up the last revision prior to the
given date, by doing something like
$ git blame <file> @{2011-12-29}
You are looking at two different dates:
a) The dates stored within the commit object:
- committer date, similarly shown by %ci: when the commit
was created.
- author date, shown by %ai: when "this" commit was "first
created".
These are properties of the commits, and thus part of the project
history. Anyone who clones the project sees the same dates.
b) The dates in the reflog, tracking the movement of *your local*
refs (like the name implies). The HEAD reflog tracks what *you*
had "currently checked out" at a given time.
An automated search in (b) is possible with the @{} syntax, but
note that it tracks the *branch state*. It says nothing about how
"current" a certain resulting commit was. For example, if you say
git checkout v1.6.0
sleep 2
git checkout -
git show '@{1 second ago}'
you will see the commit for v1.6.0 from back in 2008.
An automated search in (a) is hard, mostly because in nonlinear
history there is not usually a single (and well-defined) commit
that could be returned.
Given that we are discussing "git blame", which reports on the
history of a file (specifically the commit in which each line
originated), I think (a) must logically be included in the search
-- especially if (as in the example) the date specified is earlier
than any time in (b). Perhaps such a request needs to use some
other syntax rather than @{}, but surely the capability ought to
be provided somehow.
Git could attempt to search all of your branches, like you have
done above ...
Actually, I am not at all sure that one would want --all in the
general case; it works well in my particular case because all
branches in this repository have been merged back to master.
Intuitively, I suspect that the default search set should be all
commits reachable from HEAD. (BTW I may not have the terminology
exactly right; while I have been working with other CM systems
for a couple of decades, I am quite new to git and there is much
about it that I do not yet understand.)
but which one among all commits from that date should it pick?
The latest one that is not later than the specified date (and time
-- a timestamp within {} can provide more granularity than just
the day; in the example provided there were in fact no commits on
2011-12-29 so no ambiguity would arise from using the date alone.)
Furthermore, the result set to pick from will change if you
fetch more history into your repo.
Using the "commits reachable from HEAD" strategy above, I think
not, unless I also merge from some of that additional history.
It's even worse with the author (as opposed to committer) dates:
those are not even remotely close to monotonic in most repos,
because they are kept across rewriting. (The committer dates
would be monotonic if everyone kept their clocks in sync and
avoided filter-branch tricks.)
Since it is the file's included commits that "git blame" reports on,
I doubt it would be all that useful to deal in anything other than
commit dates. (I seem to have copy-pasted the wrong format in the
rev-list part of the example -- it should be "%h %ci".)
On Fri, Jun 15, 2012 at 06:02:39AM -0700, perryh@pluto.rain.com wrote:
quoted
You are looking at two different dates:
a) The dates stored within the commit object:
- committer date, similarly shown by %ci: when the commit
was created.
- author date, shown by %ai: when "this" commit was "first
created".
These are properties of the commits, and thus part of the project
history. Anyone who clones the project sees the same dates.
b) The dates in the reflog, tracking the movement of *your local*
refs (like the name implies). The HEAD reflog tracks what *you*
had "currently checked out" at a given time.
An automated search in (b) is possible with the @{} syntax, but
note that it tracks the *branch state*. It says nothing about how
"current" a certain resulting commit was. For example, if you say
git checkout v1.6.0
sleep 2
git checkout -
git show '@{1 second ago}'
you will see the commit for v1.6.0 from back in 2008.
An automated search in (a) is hard, mostly because in nonlinear
history there is not usually a single (and well-defined) commit
that could be returned.
Given that we are discussing "git blame", which reports on the
history of a file (specifically the commit in which each line
originated), I think (a) must logically be included in the search
-- especially if (as in the example) the date specified is earlier
than any time in (b). Perhaps such a request needs to use some
other syntax rather than @{}, but surely the capability ought to
be provided somehow.
It would have to use a different syntax, as reflog times (selected by
@{}) and commit dates (usually selected via --since and --until) are
measuring fundamentally different things, and have no meaningful
relation to each other.
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? If you were to choose
the commit with the highest timestamp <= 5, you would pick E. But there
are two independent, simultaneous lines of development, and at time=5 on
the top branch, the most current commit was C.
So the question doesn't make sense. There was no one commit at time=5;
there were multiple (as many as you have simultaneous branches). You can
pick a winner out of them, but there are multiple ways to do it. For
example, you might want to say "of all lines of development, the one
that had most recently committed as of time=5" (and of course you can
still have a tie there). Or you could say "along the first-parent
ancestry, the commit that was most recent as of time=5". I am sure one
could come up with others, as well.
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`
-Peff