Re: Clarifying "invalid tag signature file" error message from git filter-branch (and others)

"James Youngman" [off-list ref] wrote:

I used parsecvs, probably with git-master from the date of
the initial conversion (check the archives for actual date).
That was long enough ago that it was almost certainly before
git-mktag learned to be more strict about its inputs.

James, since you're about to rewrite the history, you may want to
start that process from a freshly-cvs-to-git-converted repository.

I'm not very happy about using cvsparse (considering it's not
really being maintained, afaik), so if the git crowd
can recommend something better, I'm all ears.

On Fri, Dec 12, 2008 at 11:02 AM, Jim Meyering [off-list ref] wrote:

"James Youngman" [off-list ref] wrote:

quoted

On Thu, Dec 11, 2008 at 11:13 PM, Brandon Casey [off-list ref] wrote:

quoted

quoted

Before conversion:
$ git cat-file tag FINDUTILS-4_1-10
object ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
type commit
tag FINDUTILS-4_1-10
tagger Kevin Dalley

The tagger field is missing an email address, a timestamp, and a timezone. It
should look something like:

 tagger Kevin Dalley [off-list ref] 1229036026 -0800

git-mktag prevents improperly formatted tags from being created by checking
that these fields exist and are well formed.

If you know the correct values for the missing fields, then you could

Yes for the email address.      But as for the timestamp, it's not in
the tag file; that only contains the sha1.
There is a timestamp in the object being tagged, is that the timestamp
you are talking about?

$ git show --pretty=raw  ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
commit ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
tree 752cca144d39bc55d05fbe304752b274ba22641c
parent 9a998755249b0c8c47e8657cff712fa506aa30fc
author Kevin Dalley [off-list ref] 830638152 +0000
committer Kevin Dalley [off-list ref] 830638152 +0000

    *** empty log message ***

diff --git a/debian.Changelog b/debian.Changelog
index e3541eb..d0cd295 100644
--- a/debian.Changelog
+++ b/debian.Changelog

@@ -1,5 +1,7 @@
 Sat Apr 27 12:29:06 1996  Kevin Dalley

<kevin@aplysia.iway.aimnet.com (Kevin Dalley)>

+       * find.info, find.info-1, find.info-2: updated to match find.texi
+
        * debian.rules (debian): update debian revision to 10

        * getline.c (getstr): verify that nchars_avail is *really* greater

quoted

recreate the tags before doing the filter-branch. If they are unknown, it
seems valid enough to use the values from the commit that the tag points
to.

i.e.

 tagger Kevin Dalley [off-list ref] 830638152 -0000

What tool was used to convert this repository to git? It should be corrected
to produce valid annotated tags. Especially if it is a tool within git.

I don't know, Jim Meyering will know though, so I CC'ed him.

I used parsecvs, probably with git-master from the date of
the initial conversion (check the archives for actual date).
That was long enough ago that it was almost certainly before
git-mktag learned to be more strict about its inputs.

James, since you're about to rewrite the history, you may want to
start that process from a freshly-cvs-to-git-converted repository.

Maybe, but then afaik CVS tags don't have timestamps, so some of the
data that git-mktag seems to want doesn't exist anyway.

But until we know the answer to the next question, I don't think we
know how we would generate such a freshly-converted repository.

I'm not very happy about using cvsparse (considering it's not
really being maintained, afaik), so if the git crowd
can recommend something better, I'm all ears.

Thanks,
James.

Jim Meyering wrote:

"James Youngman" [off-list ref] wrote:

quoted

On Thu, Dec 11, 2008 at 11:13 PM, Brandon Casey [off-list ref] wrote:

quoted

quoted

What tool was used to convert this repository to git? It should be corrected
to produce valid annotated tags. Especially if it is a tool within git.

I don't know, Jim Meyering will know though, so I CC'ed him.

I used parsecvs, probably with git-master from the date of
the initial conversion (check the archives for actual date).
That was long enough ago that it was almost certainly before
git-mktag learned to be more strict about its inputs.

James, since you're about to rewrite the history, you may want to
start that process from a freshly-cvs-to-git-converted repository.

I'm not very happy about using cvsparse (considering it's not
really being maintained, afaik), so if the git crowd
can recommend something better, I'm all ears.

I've only used git-cvsimport. AFAIK it creates light-weight tags in
git rather than annotated tags.

It also uses an unmaintained tool: cvsps. There are some additional
patches in a git repository somewhere that fix a few known problems.

You could try that James.

-brandon

Jim Meyering [off-list ref] writes:

I used parsecvs, probably with git-master from the date of
the initial conversion (check the archives for actual date).
That was long enough ago that it was almost certainly before
git-mktag learned to be more strict about its inputs.

James, since you're about to rewrite the history, you may want to
start that process from a freshly-cvs-to-git-converted repository.

I'm not very happy about using parsecvs (considering it's not
really being maintained, afaik), so if the git crowd
can recommend something better, I'm all ears.

The page you might want to consult is

  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools

There you have listed git-cvsimport, which uses cvsps to extract
patchset, is in git, and is as far as I know the only tool that allow
incremental import; parsecvs which requires access to *,v files you
use; cvs2svn (cvs2git) which have learned fast-import format and can
be used to import (fast) CVS repositories, but incremental import
(difficult that it is) is only in plans, AFAIK.

So I would recommend trying cvs2svn / cvs2git.
-- 
Jakub Narebski
Poland
ShadeHawk on #git