git-cvsimport bug with dates

git-cvsimport bug with dates

[Elijah Newren]

Hi,

It appears that there's some kind of bug with git-cvsimport and dates.
 In a small repository I imported on Oct 24, I'm getting:

$ git log | grep ^Date | wc -l
957
$ git log | grep ^Date | tail
Date:   Tue Oct 29 21:10:17 2002 +0000
Date:   Tue Oct 29 17:41:05 2002 +0000
Date:   Tue Oct 29 00:43:27 2002 +0000
Date:   Mon Oct 28 23:36:40 2002 +0000
Date:   Mon Oct 21 21:35:57 2002 +0000
Date:   Fri Sep 20 22:18:01 2002 +0000
Date:   Mon Sep 16 20:05:27 2002 +0000
Date:   Wed Sep 11 21:14:03 2002 +0000
Date:   Tue Sep 10 16:37:16 2002 +0000
Date:   Fri Aug 23 16:03:22 2002 +0000
$ git diff @{2007-10-01}
warning: Log for '' only goes back to Wed, 24 Oct 2007 19:31:38 +0000.
fatal: bad object @{2007-10-01}


It appears that passing a date to git diff on any repository imported
by git-cvsimport will show this error, as long as the date is prior to
when the repository was imported.


Elijah

Re: git-cvsimport bug with dates

[Junio C Hamano]

"Elijah Newren" <newren@gmail.com> writes:

> $ git diff @{2007-10-01}
> warning: Log for '' only goes back to Wed, 24 Oct 2007 19:31:38 +0000.
> fatal: bad object @{2007-10-01}
>
>
> It appears that passing a date to git diff on any repository imported
> by git-cvsimport will show this error, as long as the date is prior to
> when the repository was imported.

That is not a cvsimport specific issue.

When you use "branch@{date}" notation, you are not asking a
question on the project history, but a question on the local
view from _your_ repository on that project.

	$ git log --since=3.days.ago master

asks "go back from the master tip and show commits until you hit
the commit made earlier than that date and stop traversing".

On the other hand,

	$ git show master@{3.days.ago}

asks "show the commit that was the tip of 'master' branch in my
repository three days ago."  Maybe you pulled from your upstream
5 minutes ago, and the last time before that, you pulled three
weeks ago and did not do any development on the branch.  In such
a case, the latter question will give you the tip of your
'master' as of three weeks ago which is the same as of three
days ago.

Re: git-cvsimport bug with dates

[Elijah Newren]

On Nov 15, 2007 11:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> When you use "branch@{date}" notation, you are not asking a
> question on the project history, but a question on the local
> view from _your_ repository on that project.

Interesting; that makes sense from a merge or pull viewpoint, but
wouldn't it make more sense to have cvsimport ensure the commits are
treated as though they actually existed in master as of the date
specified in CVS?

Elijah

Re: git-cvsimport bug with dates

[Robin Rosenberg]

fredag 16 november 2007 skrev Elijah Newren:
> On Nov 15, 2007 11:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > When you use "branch@{date}" notation, you are not asking a
> > question on the project history, but a question on the local
> > view from _your_ repository on that project.
> 
> Interesting; that makes sense from a merge or pull viewpoint, but
> wouldn't it make more sense to have cvsimport ensure the commits are
> treated as though they actually existed in master as of the date
> specified in CVS?

Reflog do not work that way. They don't say when a commit entered a repo,
only when a ref changed. For a CVS import things could work as you suggest
but I think the confusion among newcomers would be massive if people start
using reflogs  'as if' it said anyting about when a commit entered. It can be used
as a hint.

Reflogs get pruned by git-gc and are not cloned (cannot be since they store
local-only information.

Use the --since and --until switches instead.

-- robin

Re: git-cvsimport bug with dates

[Elijah Newren]

On Nov 17, 2007 3:12 AM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> fredag 16 november 2007 skrev Elijah Newren:
>
> > On Nov 15, 2007 11:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > > When you use "branch@{date}" notation, you are not asking a
> > > question on the project history, but a question on the local
> > > view from _your_ repository on that project.
> >
> > Interesting; that makes sense from a merge or pull viewpoint, but
> > wouldn't it make more sense to have cvsimport ensure the commits are
> > treated as though they actually existed in master as of the date
> > specified in CVS?
>
> Reflog do not work that way. They don't say when a commit entered a repo,
> only when a ref changed. For a CVS import things could work as you suggest
> but I think the confusion among newcomers would be massive if people start
> using reflogs  'as if' it said anyting about when a commit entered. It can be used
> as a hint.

Okay...so I guess my suggestion could be translated as: don't worry
about when the commit entered; instead make git-cvsimport mark the
refs as changed as of the CVS date mentioned instead of as of the
import time.

I guess there would be reluctance to do this whenever git-cvsimport
would be used for incremental commits on a repository that also had
local commits?  Sounds like the issue is deeper than I first realized
and this probably isn't worth the effort it'd take.

Thanks for the explanations.

Elijah

Re: git-cvsimport bug with dates

[Jan Hudec]

On Sat, Nov 17, 2007 at 08:39:08 -0700, Elijah Newren wrote:
> Okay...so I guess my suggestion could be translated as: don't worry
> about when the commit entered; instead make git-cvsimport mark the
> refs as changed as of the CVS date mentioned instead of as of the
> import time.
> 
> I guess there would be reluctance to do this whenever git-cvsimport
> would be used for incremental commits on a repository that also had
> local commits?  Sounds like the issue is deeper than I first realized
> and this probably isn't worth the effort it'd take.

Actually local commits don't need to be involved at all. Incremental import
is enough.

One good reason to use reflog is when you notice something does not work and
recall, that it worked yesterday evening. Than you need to know what you were
looking at at that time, not at what was latest, because you didn't
necessarily have to be up-to-date.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>