Re: checking out by date

David Bryson· Jan 12, 2009, 19:30 UTC · lore

checking out by date

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

Boyd Stephen Smith Jr.· Jan 12, 2009, 19:58 UTC · re: David Bryson · lore

On Monday 2009 January 12 13:30:39 David Bryson wrote:

Show 23 quoted lines

>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/                      \_/

Robin Rosenberg· Jan 12, 2009, 21:24 UTC · re: David Bryson · lore

David Bryson <david@statichacks.org> writes:

Show 10 quoted lines

> 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