Re: How to check out the repository at a particular point in time

I understand. However, let's see if git can cope with this pretty common scenario:

Say I'm a developer with too many projects and little time. I don't really want to find the commit ID at each release and manually make a note on the project's web site. In fact, I have no "official" releases. The "contract" with my users (or co-developers in my team) is simple: check out HEAD, it should always work. If it doesn't, last week it worked well, check out at that point in time and wait until I fix the HEAD.

Now you're saying I cannot reliably checkout last week's versions because yesterday I did a merge from an older branch? You mean that git stores everything with clean graphs and numeric pointers, so it cannot know what this repository looked like last week?

As the developer, I have full control, I can decide what the branches are called and how the public repository is updated/pushed/whatever. I can control the clock so there are no time skews.

What do I have to do in order to be able to reliably checkout last week's versions without too much administrative work? I just want to get the same result today as if I had done a checkout last week from the public repository and had made a back-up copy of the working directory then.

With say CVS and Subversion, that's piece of cake, they already work that way, I don't need to manually keep track of revision IDs or visually inspect the merge tree.

Thanks for your answers,
  R. Diez

R. Diez wrote:

Please stop using HEAD like this, you'll just confuse your coworkers (and yourself). HEAD denotes the currently checked out commit. [Unlike SVN it is *not* the most recent version of anything.] Thus by definition, 'git checkout HEAD' is a no-op.

The newest commit on a branch is denoted by its branch name, because as Jens said, a branch is in fact a pointer to its tip[1] commit.

Indeed. Especially if forced pushes are allowed, there is no way to know what was in the repo at a given time unless you have (local) reflogs enabled on remote branches and going back until the time you want.

Assuming

* you never do a non-fast-forward (i.e., forced) push
* you never have any clock skew
* you always merge features into master (not the other way around)
* you always push immediately after committing on master

you can get there by using 'git log -1 --first-parent --until=...' as mentioned in my first email.

I personally think that's crazy and -- if you want to avoid the work of "really" using submodules -- support Jens's suggestion of having the buildbot automatically assemble an "I tested this" superproject.

[1] or "head" in lowercase (thus "branch head"), but I prefer tip to avoid confusion

On Tue, Aug 23, 2011 at 2:17 AM, Thomas Rast <trast@student.ethz.ch> wrote:

Or create a tag in each separate repository, using the same tag name to indicate versions that were tested together. Or you could do the same with a branch, since a branch is basically a tag that moves. You would just have to make sure only the buildbot updated that branch.

-PJ

Am 23.08.2011 12:04, schrieb PJ Weisberg:

That would also work, but it might need some scripting. Probably having some server side hooks to enforce the policy allowing no-one except the buildbot to change those branches/tags would help here. Also submodules would make it easier to see when they differ from the commits recorded in the superproject, so a script running something like "git describe" in all local repos and displaying the results might be a good idea to get that information.