checking out by date

checking out by date

[David Bryson]

Hi All,

I have a very large repository that imported into git from CVS with
about 5 years worth of history.

Today I decided to checkout some code from the past:

$ git checkout master@{"Mon Dec 31  2007"}
warning: Log for 'master' only goes back to Tue, 2 Dec 2008 16:57:15
-0800.

Then proceeds to checkout a code snapshot from 2 Dec.  To work around
this I checked out a specific commit id, by looking at the log:

commit 3771ec1d6ccf329da378b7633fdef60474eac4b7
Author: XXXXXXXXXXXXXXX
Date:   Mon Dec 31 23:25:17 2007 +0000

    BugId: none
    correct wrong commit


$ git checkout 3771ec1d6ccf329da378b7633fdef60474eac4b7
...
HEAD is now at 3771ec1... BugId: none correct wrong commit

So what has caused git to be unable to process the date information,
even though the information is clearly in the history ?  Did I miss
something ?

Dave

Re: checking out by date

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

On Monday 2009 January 12 13:30:39 David Bryson wrote:
>I have a very large repository that imported into git from CVS with
>about 5 years worth of history.
>
>Today I decided to checkout some code from the past:
>
>$ git checkout master@{"Mon Dec 31  2007"}
>warning: Log for 'master' only goes back to Tue, 2 Dec 2008 16:57:15
>-0800.
>
>Then proceeds to checkout a code snapshot from 2 Dec.  To work around
>this I checked out a specific commit id, by looking at the log:
>
>commit 3771ec1d6ccf329da378b7633fdef60474eac4b7
>Author: XXXXXXXXXXXXXXX
>Date:   Mon Dec 31 23:25:17 2007 +0000
>
>$ git checkout 3771ec1d6ccf329da378b7633fdef60474eac4b7
>...
>HEAD is now at 3771ec1... BugId: none correct wrong commit
>
>So what has caused git to be unable to process the date information,
>even though the information is clearly in the history ?  Did I miss
>something ?

The ref@{date} format uses the reflogs which are expired regularly, IIRC.  
Also, I don't think reflogs are built by cvsimport, so they would only go 
back to the import date.

While there is date information in the output of 'git log', some of those 
commits may never have been pointed to by the named ref, so they wouldn't 
satisfy the semantics of "$ref as it was on $date".  With a linear history, 
this "only" puts you in the middle of a fast-forward, which isn't *that* bad.

However, with a non-linear history, taking the ancestor with the latest commit 
date before the given date might end up checking out a topic branch that 
hadn't yet been merged on that date, which could be incredibly confusing.

It should be possible to introduce a commit "spelling" to enable 
checkout-by-date, but I don't know of one currently.  Something 
like "commitish~{date}" meaning "commitish~n where n is the largest value 
s.t. commit_date(commitish~n) <= date", intentionally taking the first parent 
on any merge to discard the merge event.

If this is a feature we feel is valuable, I don't think it would be that hard 
to code.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: checking out by date

[Robin Rosenberg]

David Bryson <david@statichacks.org> writes:
> Hi All,
> 
> I have a very large repository that imported into git from CVS with
> about 5 years worth of history.
> 
> Today I decided to checkout some code from the past:
> 
> $ git checkout master@{"Mon Dec 31  2007"}
> warning: Log for 'master' only goes back to Tue, 2 Dec 2008 16:57:15
> -0800.

git checkout $(git rev-list -n1 --before="Mon Dec 31  2007 23:59:59")

-- robin