error on pull: fatal: Invalid raw date "" in ident: remote-hg <>

[jcb91]

Hi there.
I'm using using mercurial 2.7.1, git 1.7.9 and python 2.7.3 from cygwin. I'm trying to clone an existing hg repository, but see a fatal error. I provide below my sequence of events, I do an init first because if I just do a clone, the .git directory containing crashdumps is removed on failure and I can't read them.

$ git init sapphire; cd sapphire
$ git remote add origin hg::https://code.google.com/p/pi3diamond
$ git pull
requesting all changes
adding changesets
adding manifests
adding file changes
added 473 changesets with 1482 changes to 416 files (+6 heads)
progress revision 0 'jan' (0/268)
progress revision 100 'jan' (100/268)
progress revision 200 'jan' (200/268)
fatal: Invalid raw date "" in ident: remote-hg <>
fast-import: dumping crash report to .git/fast_import_crash_5936
fatal: Error while running fast-import
Traceback (most recent call last):
  File "/usr/bin/git-remote-hg", line 1240, in <module>
    sys.exit(main(sys.argv))
  File "/usr/bin/git-remote-hg", line 1222, in main
    do_import(parser)
  File "/usr/bin/git-remote-hg", line 676, in do_import
    export_branch(repo, branch)
  File "/usr/bin/git-remote-hg", line 571, in export_branch

Googling, I found a similar error messages produced by fast-export, at
frej/fast-export#15, which seems to be the result of a mangled author. I note that the list of authors from a cloned version of the mercurial repository

$ hg log --template '{author}\n' | sort | uniq > authors.txt

doesn't seem to have anything obviously problematic (spurious < or >), but contains one line just noting User, so wondered whether that might be a blank one? I tried looking for options to provide author mappings, but couldn't find one for remote helpers. I'm probably way off the mark here, but I've reached the limit of my understanding at any rate. Any ideas?

[felipec]

It is working fine here, even on Git 1.7.9.

From the looks of it, this is failing:

import time as ptime
print "committer remote-hg <> %s" % (ptime.strftime('%s %z'))

What happens when you run that in python?

[jcb91]

Well, (ptime.strftime('%s %z')) just returns an empty string from my cygwin python distribution (which I is the one being called from cygwin bash), while from my enthought canopy python distribution on the same machine throws a

ValueError: Invalid format string

Looking at the python docs, I guessed that maybe you meant the uppercase version,

strftime('%S %Z')

which gives (e.g.)

'51 BST'

from cygwin python, or (confusingly for me, since they both claim to be 2.7.3),

'51 GMT Daylight Time'

from enthought canopy distribution. Now I think about it though, if you meant an error to be thrown by an invalid format, then it isn't happening. Does any of that make sense?

[jcb91]

looking at this SO post, I realize that neither %s nor %z are officially supported by python. To paraphrase, they may work on some (most?) platforms if python passes the argument to the system strftime.

So, I think I've come up with a replacement which doesn't rely on the problematic formats, but uses the already-existing gittz method:

import time as ptime
print "committer remote-hg <> %d %s" % (ptime.time(), gittz(ptime.timezone) )

It seems to fix my original issue, although I now get:

Cloning into 'sapphire'...
requesting all changes
adding changesets
adding manifests
adding file changes
added 473 changesets with 1482 changes to 416 files (+6 heads)
progress revision 0 'master' (0/441)
progress revision 100 'master' (100/441)
progress revision 200 'master' (200/441)
progress revision 300 'master' (300/441)
progress revision 400 'master' (400/441)
WARNING: Branch 'FPGA___based___TimeTagger' has more than one head, consider merging
error: git-remote-hg died of signal 6

I guess this is unrelated, but can't find from git-remote-hg.py where this return value comes from, so maybe not. Should I submit this as a separated issue?

[jcb91]

Having looked into it, I find that signal 6 is SIGABRT, so probably a much more low-level bug in one of my distributions somewhere. As far as I can tell, git-remote-hg gets all the way through to the end of main(), and even calls bye(), which runs all the way through marks.store(), so it seems the SIGABRT can only come at sys.exit(), so maybe it's not a big deal as far as my repo goes. Not really sure how to check, though.
Thanks for your help thus far.

[felipec]

looking at this SO post, I realize that neither %s nor %z are officially supported by python.

Yes. I was afraid this was the problem. Fortunately the code you proposed looks fine as a replacement.

Having looked into it, I find that signal 6 is SIGABRT, so probably a much more low-level bug in one of my distributions somewhere.

You should probably open another bug report for that one. I would try to play with different simple scripts, sys.exit() and so on to try to narrow down the problem.

[jcb91]

I've made a pull request for the edit, I'm not really sure whether that was the right thing to do, or whether I should have made a branch first, I'm a bit new to this. Let me know if I should be doing something else.

For the SIGABRT, where should I open a bug, on the same file? I sort of assumed it was more to do with my python stack, so was reluctant to pin it on here.

[felipec]

It is all right, I've merged the fix.

As for the SIGABRT issue. I suggest you investigate if the issue is indeed with your python or not, and whether we can do anything about it in git-remote-hg.