Hallo Thomas Rast:
Thanks for your quick answer. Please see mine below.
> 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.
OK, thanks. That kind of example would be nice to have in the "git checkout" documentation page. In the meantime, I've seen on the Internet that other people also got caught by this... let's say... 'unintuitive' behaviour or documentation. 8-)
> It is a git-log option (or more precisely, revision walker
> option).
In the meantime, I've seen this done with "git rev-list" instead, like this:
git rev-list -n 1 --before="2010-11-01 11:45:16 +0000" master
Is that the same as with git-log ?
> 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?
I still don't quite understand how git works, but let me risk a naive statement here. If "a-b-c-M" were 'master', and "d-e-f" were 'new-feature', then on April 1st the current version on 'master' is 'b', because I merged the 'new-feature' branch at a later point in time. Does that make sense?
> Step back and consider the real problem here. In the
You're right in saying there is a race condition here between developers, and the right solution would be of course to tag which versions work well with each other.
But that problem the daily build is trying to solve is precisely that it's too hard to keep track of all component versions in all repositories. Things just move too fast, and as far as I understand it, git submodules require manual intervention. If I ever tag anything manually, it must have already passed the daily build!
The development model looks like this: the latest HEAD versions of all components should always work well with each other. If something breaks, the daily build will let the developer know by the next day. If two developers make incompatible changes, they'll speak to each other and commit their changes within a few hours. During that time, they will be trouble, but that's quite alright (at least for the moment).
I just didn't want the daily build to add to the uncertainty of what went wrong by introducing a few hours' worth of random time skew to the mix.
The daily build server needs to check out from git the head status at say 02:00 am on all repositories, as if the server had so many CPUs that it had ran a "git pull" for all of them simultaneously. That's close enough for my purposes. Like stated above, if someone merges some old branch at 02:01 am, a user that did a "git pull" on master at 02:00 am would not have seen that merge, that's the effect I would like to achieve.
In the future there will probably be a stable HEAD branch and a development branch with the same name across all git repositories, and the daily build can do both every day. Or maybe the stable versions will not come from git any more, but from .tar.gz files. Another solution to automate releases without so much human intervention would be as follows: if the automated build and automated testing succeeded 3 hours ago, then that timestamp can be entered in the database of "pretty sure it works" versions. The timestamp becomes effectively the version number. Manually coordinating all participants is hard if you don't have so many human resources.
Thanks again,
R. Diez
--
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