threads / bug / 10895

git-cvsimport bug with dates

Subject: git-cvsimport bug with dates

## tl;dr

6 messages between Nov 16, 2007 and Nov 17, 2007.

replies: 5people: 4as markdown or json

Elijah Newren· Nov 16, 2007, 04:59 UTC · lore
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
Junio C Hamano· Nov 16, 2007, 06:06 UTC · re: Elijah Newren · lore

Re: git-cvsimport bug with dates

"Elijah Newren" <newren@gmail.com> writes:
Show 8 quoted lines
> $ 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.

Elijah Newren· Nov 16, 2007, 14:12 UTC · re: Junio C Hamano · lore

Re: git-cvsimport bug with dates

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
Robin Rosenberg· Nov 17, 2007, 10:12 UTC · re: Elijah Newren · lore

Re: git-cvsimport bug with dates

fredag 16 november 2007 skrev Elijah Newren:
Show 9 quoted lines
> 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
Elijah Newren· Nov 17, 2007, 15:39 UTC · re: Robin Rosenberg · lore

Re: git-cvsimport bug with dates

On Nov 17, 2007 3:12 AM, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:

Show 17 quoted lines
> 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
Jan Hudec· Nov 17, 2007, 21:36 UTC · re: Elijah Newren · lore

Re: git-cvsimport bug with dates

On Sat, Nov 17, 2007 at 08:39:08 -0700, Elijah Newren wrote:
Show 9 quoted lines
> 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>

← back to recent threads