The current code miscalculates the time-zone offsets for time zones that don't
have a full-hour offset and are located west of UTC (e.g. St. John's,
Newfoundland).
Basically it's caused because 33 // 10 == 3, but -33 // 10 != -3.
Take the example of St. John's (-0330). The correct integer timezone should be
3.5 * 3600 (12600), however, since we are not checking for negative module
arithmetic, instead of calculating the timezone for (-3, -30), we are doing it
for (-4, 70), which would be OK... if we had hours of 100 minutes:
-4 * 100 + 70 = -330
We could fix the code to use proper negative arithmetic (mod -100), but why
bother with the extra complexity? Let's just use absolute numbers and fix the
sign later.
This fixes issue #48.
Commit message written by Felipe Contreras.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Oliver Stueker pointed out correctly that there is an issue with the way
we handle negative timestamps that don't have a full hour offset.
This test shows that.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
The Hg-Git project has put a lot of emphasis on file renaming, better
check for that explicitly, even though we are already testing that.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Since version 0.7.0 hg-git stores extra information directly into the
commits, we don't support that, so we need to tell hg-git to do what it
always did: put the extra data in the message.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
A complete solution for submodules might be to convert them to hg
subrepositories. But this would, in the general case, be quite
difficult -- for instance, local copies of all historical submodule
commits might not be available, and repositories might have moved
around.
It's better to do the conversion in some understandable way than to
crash with a weird error message, so let's do that.
... so discard it altogether when reading marks.
All this also removes fetch-first error which is either no error at all or
is either really a non-fast-forward error.
Push capability is used depending on remote-hg.capability-push setting and ...
* handles dry-run properly,
* passes copy and rename information onto Mercurial
Fixesfelipec/git-remote-hg#61
Also prevent errors when trying to push no changesets to a peer, which some
combinations of versions and extensions do not handle well;
see e.g. as in felipec/git-remote-hg#32 and felipec/git-remote-hg#22
This reverts commit f53a8653ab.
It turns out Debian and Fedora do provide the C.UTF-8 locale, but other
distributions don't.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
The en_US.UTF-8 locale is not guaranteed to exist, and if it doesn't,
several tests fail.
Signed-off-by: Paul Wise <pabs3@bonedaddy.net>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
