Re: How to (re-)create .git/logs/refs

[Holger Schurig <hs4233@mail.mn-solutions.de>]

> 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.