> Are you sure you understand what @{date} does? It shows you
> the state _this_ repository was in at that date.
Who says so? "man git-rev-parse" just says:
o A ref followed by the suffix @ with a date specification
enclosed in a brace pair (e.g. {yesterday}, {1 month 2 weeks 3
days 1 hour 1 second ago} or {1979-02-26 18:30:00}) to specify
the value of the ref at a prior point in time. This suffix may
only be used immediately following a ref name and the ref
must have an existing log ($GIT_DIR/logs/<ref>).
It just states "at a prior point in time", not "at a prior point
in time in your git repository/checkout".
> It is a common misconception that you can reference anything
> by date in a distributed setup. (Before you ask, I will just
> mention "clock skew" and "parallel branches" to give you an
> idea why this is a misconception.)
My idea was to use the first commit (from git-rev-log) where the
date is below the specified date.
To give you some context: Bitbake (from www.openembedded.org) is
a tool that can download software, patch it, configure it,
compile it and create packages out of it. Nothing fancy, except
that it can do this for a huge amount of embedded devices,
usually using a cross-compiler for ARM, MIPS, whatever.
And it can download not just tar files, it can also use CVS, SVN,
hg, git and so on.
In Openembedded, many patch recipes specify the version to use.
If you deal with versioned stuff, e.g.
filename-frob-3.14.tar.bz, this is fine. Sometimes the version
is a SVN revision number. And sometimes it's a git, mercury or
monotone hash. However, the latter beast are almost
non-describing. So many bitbake recipes specify a SRCDATE, and
you can immediately see if SRCDATE=20070501 that it uses an
ancient version of the software, from 1st May 2007. You won't
see that if it would specify
GIT_REV=6e2df4fd066c450b0b3c8e0f1769d4163e2b52c4. Of course you
can do
GIT_REV=6e2df4fd066c450b0b3c8e0f1769d4163e2b52c4
# This is from 2007 May 1st
but then you're redundant and chances are high that those two
lines get out-of-sync.
So, when I have SRCDATE=20070501, I'd be happy if git would, for
me, find out that this is
6e2df4fd066c450b0b3c8e0f1769d4163e2b52c4, even when the commit
6e2df4fd066c450b0b3c8e0f1769d4163e2b52c4 was not done on my
local machine, but is a commit that I pulled from the outside.
Also, when I do "git checkout @{20070501}", I don't usually mind
if, e.g. because of time-skew or multi-heads, I'm not at the
17th commit in this area, but on the top-most for which this
condition is true. I can use "git log" and "git reset" or
whatever to dig my way to the state I want, but git would do the
dull work for me.
--
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
