error on pull: fatal: Invalid raw date "" in ident: remote-hg <> about git HOT 7 CLOSED

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?

from git.

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?

from git.

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?

from git.

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.

from git.

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.

from git.

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.

from git.

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.

from git.