I'll basically reply from bottom up so you can see the motivation and
then my suggestions for the solution.
R. Diez wrote:
>
> Note that this looks up the state of your local ref at
> a given time; e.g., what was in your local master branch last week.
> If you want to look at commits made during certain times,
> see --since and --until.
[...]
> Say, for example, an hour ago I had temporarily checked out last
> year's versions, but half an hour ago I went back to this year's
> versions. If I check out at HEAD@{1 hour ago}, will I get then last
> year's version, or this year's?
The @{date} and @{n} syntax refers to the reflog, which as the name
tries to imply, is a log of where *your local ref* was at that
time/step. Since the HEAD ref is by definition what you have checked
out at the moment, HEAD@{1 hour ago} indeed refers to last year's
version.
> Anyway, my real problem is with the mentioned --until option. "git
> checkout" does not understand that option, so I guess I need to feed
> the date to some other git command in order to get the commit ID for
> "git checkout", right? Can someone help me here?
It is a git-log option (or more precisely, revision walker option).
The main problem is that your request is not very well-defined: in
nonlinear history there will in general be more than one commit at the
time requested.
---a----b----c----M---- (M is a merge)
\ /
d-----e----f
^---- April 1st
Suppose you ask git for "the newest commit as of April 1st" in this
history. Is it supposed to give you b or d? [If you think nonlinear
history is easy, try to figure out a good rule in the presence of time
skew, where misconfigured clocks/timezones resulted in parents being
younger than children.]
Hence:
> For extra karma points, git checkout could understand the --until option itself.
It probably never will, because that is an ill-defined request.
You can indeed say
git log -1 --until="april 1"
to get *one* commit that happened before April 1st, but which one is
up to the order internally used by git. You can also say
git log -1 --first-parent --until="april 1"
to get the first such commit along the first-parent ancestry, which
might suit the ticket.
But there is a more fundamental issue. Let me explain.
> I'm writing a daily build script for all the OpenRISC components, so
> every day I need to check out several git repositories with the
> source code of many tools that depend on each other.
>
> The hole process takes hours. In order to minimize the risk of
> repository skew
Step back and consider the real problem here. In the simplest case
you are getting two components A and B which depend on each other,
e.g., A depends on B. But there is a race condition in the case where
a user updates an API between them in a backward-incompatible way: she
has to update both A and B, and an unfortunate coworker/buildbot may
pull old-A and new-B (or vice versa) and get a broken build.
[Incidentally this seems to be a frequent problem with SVN externals.]
You might say: if only we had a way to record the fact that the
"blessed" version of B to go with old-A is old-B, and for new-A it's
new-B.
And indeed we do. Submodules were invented to allow B to be "linked"
into A's repository, such that a checkout of any commit of A "knows"
the correct corresponding version of B. A user who updates the API
can record the update to B inside the API-changing commit in A.
So while you can kludge your way around the problem with clever use of
'git log --until', submodules would be the "correct" solution.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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