Holger Schurig <hs4233@xxxxxxxxxxxxxxxxxxxx> writes:
> > 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".
Please read carefully: "value of the _ref_" at a given time.
It means value where ref pointed to at given time. That of
course depends on what you did with repository: did you just fetch,
or perhaps you made those commits, or perhaps you rebased branch,
or decided that the work you did is wrong and rewound to previous
version using reset.
As this is purely local matter, it matter only for _your_
repository.
> > 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.
Which might be not what you want, as you can get revision which
was on some side branch.
> 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.
Thanks for explanation. This is most useful when proposing solutions
to real problem...
The solution, of course, is to use git-describe output instead of
full SHA-1 (this of course assumes that you tag your releases).
Something like "v1.5.5.1-215-gc853afb" is, I think, quite well
self-described. There is still place for ambiguity due without
the shortened sha-1 part due to parallel development, but I think
no less than using date.
> 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.
You can try
$ git checkout "$(git log -1 --pretty=format:%H --before=2007-05-01)"
but YMMV, i.e. if you hit upon correct revision or not would depend
on luck.
--
Jakub Narebski
Poland
ShadeHawk on #git
--
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
