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

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

[James Youngman]

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

What do the errors "error: char88: malformed tagger field" and "fatal:
invalid tag signature file" and "Could not create new tag object for
FINDUTILS-4_1-10" signify in the session below?

Are any of those errors correctable (I can re-run the tree rewrite
script as many times as needed, I'm just using it on a test repository
for now).

The script I'm invoking calls git filter-branch; I've attached the script.

$ bash ~/source/GNU/findutils/logrewrite.sh
fatal: Not a git repository
Rewrite 9afb13614381c4bfa22f515c18cbfe6f54798330 (1587/1587)
Ref 'refs/heads/master' was rewritten
FINDUTILS-4_1-10 -> FINDUTILS-4_1-10
(ce25eb352de8dc53a9a7805ba9efc1c9215d28c2 ->
79221244237bc408ced0c37f3c3476d53e665801)
error: char88: malformed tagger field
fatal: invalid tag signature file
Could not create new tag object for FINDUTILS-4_1-10
$

Thanks,
James.

[-- Attachment #2: logrewrite.sh --]
[-- Type: application/x-sh, Size: 1401 bytes --]

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

[Brandon Casey]

James Youngman wrote:
> What do the errors "error: char88: malformed tagger field" and "fatal:
> invalid tag signature file" and "Could not create new tag object for
> FINDUTILS-4_1-10" signify in the session below?

It means the tagger field in the tag does not follow the correct form.
Specifically the testing in git-mktag (called by filter-branch) does:

         * Check for correct form for name and email
         * i.e. " <" followed by "> " on _this_ line
         * No angle brackets within the name or email address fields.
         * No spaces within the email address field.

What does 'git cat-file tag FINDUTILS-4_1-10' show you?

> Are any of those errors correctable (I can re-run the tree rewrite
> script as many times as needed, I'm just using it on a test repository
> for now).

If there are only a few, then you can manually retag with a corrected
tagger field, and then run your script.

Of course, depending on the output of the cat-file call above, the
testing in git-mktag may need to be relaxed.

-brandon

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

[James Youngman]

On Thu, Dec 11, 2008 at 9:06 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> James Youngman wrote:
>> What do the errors "error: char88: malformed tagger field" and "fatal:
>> invalid tag signature file" and "Could not create new tag object for
>> FINDUTILS-4_1-10" signify in the session below?
>
> It means the tagger field in the tag does not follow the correct form.
> Specifically the testing in git-mktag (called by filter-branch) does:
>
>         * Check for correct form for name and email
>         * i.e. " <" followed by "> " on _this_ line
>         * No angle brackets within the name or email address fields.
>         * No spaces within the email address field.
>
> What does 'git cat-file tag FINDUTILS-4_1-10' show you?

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

The conversion:

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

This is in the repo at
http://git.savannah.gnu.org/gitweb/?p=findutils.git;a=commit;h=ce25eb352de8dc53a9a7805ba9efc1c9215d28c2

>> Are any of those errors correctable (I can re-run the tree rewrite
>> script as many times as needed, I'm just using it on a test repository
>> for now).
>
> If there are only a few, then you can manually retag with a corrected
> tagger field, and then run your script.
>
> Of course, depending on the output of the cat-file call above, the
> testing in git-mktag may need to be relaxed.
>
> -brandon
>

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

[Brandon Casey]

James Youngman wrote:
> On Thu, Dec 11, 2008 at 9:06 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> James Youngman wrote:
>>> What do the errors "error: char88: malformed tagger field" and "fatal:
>>> invalid tag signature file" and "Could not create new tag object for
>>> FINDUTILS-4_1-10" signify in the session below?
>> It means the tagger field in the tag does not follow the correct form.
>> Specifically the testing in git-mktag (called by filter-branch) does:
>>
>>         * Check for correct form for name and email
>>         * i.e. " <" followed by "> " on _this_ line
>>         * No angle brackets within the name or email address fields.
>>         * No spaces within the email address field.
>>
>> What does 'git cat-file tag FINDUTILS-4_1-10' show you?
> 
> 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 <kevin.dalley@somewhere.com> 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
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 <kevin@seti.org> 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.


The tag below was actually not converted. filter-branch bailed
out during the conversion and so left it alone.

> The conversion:
> 
> After conversion:
> $ git cat-file tag FINDUTILS-4_1-10
> object ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
> type commit
> tag FINDUTILS-4_1-10
> tagger Kevin Dalley
> 
> This is in the repo at
> http://git.savannah.gnu.org/gitweb/?p=findutils.git;a=commit;h=ce25eb352de8dc53a9a7805ba9efc1c9215d28c2

-brandon

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

[James Youngman]

On Thu, Dec 11, 2008 at 11:13 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:

>> 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 <kevin.dalley@somewhere.com> 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 <kevin@seti.org> 830638152 +0000
committer Kevin Dalley <kevin@seti.org> 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





> 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 <kevin@seti.org> 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.


> The tag below was actually not converted. filter-branch bailed
> out during the conversion and so left it alone.

I see.

Thanks,
James.

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

[Jim Meyering]

"James Youngman" <jay@gnu.org> wrote:
> On Thu, Dec 11, 2008 at 11:13 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>
>>> 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 <kevin.dalley@somewhere.com> 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 <kevin@seti.org> 830638152 +0000
> committer Kevin Dalley <kevin@seti.org> 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
>
>
>
>
>
>> 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 <kevin@seti.org> 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.

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.

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

[James Youngman]

On Fri, Dec 12, 2008 at 11:02 AM, Jim Meyering <jim@meyering.net> wrote:
> "James Youngman" <jay@gnu.org> wrote:
>> On Thu, Dec 11, 2008 at 11:13 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>>
>>>> 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 <kevin.dalley@somewhere.com> 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 <kevin@seti.org> 830638152 +0000
>> committer Kevin Dalley <kevin@seti.org> 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
>>
>>
>>
>>
>>
>>> 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 <kevin@seti.org> 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.

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

[Brandon Casey]

Jim Meyering wrote:
> "James Youngman" <jay@gnu.org> wrote:
>> On Thu, Dec 11, 2008 at 11:13 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:

>>> 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

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

[Jakub Narebski]

Jim Meyering <jim@meyering.net> 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

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

[Brandon Casey]

James Youngman wrote:
> On Thu, Dec 11, 2008 at 11:13 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> 
>>> 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 <kevin.dalley@somewhere.com> 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?

Yes and no. I meant that if you knew the "real" timestamp, possibly by
extracting it from the original repository, then you can use that.
Otherwise yes, as a workaround, use the timestamp in the object being
tagged.

> $ git show --pretty=raw  ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
> commit ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
> tree 752cca144d39bc55d05fbe304752b274ba22641c
> parent 9a998755249b0c8c47e8657cff712fa506aa30fc
> author Kevin Dalley <kevin@seti.org> 830638152 +0000
> committer Kevin Dalley <kevin@seti.org> 830638152 +0000

The committer information should be used, though in this repository it will
probably always be the same as the author.

-brandon