The Python scripts have unversioned Python shebangs so tests will
fail if the chosen Python version is not unversioned Python.
Copy the scripts to tmp dirs and change the shebang to the chosen Python.
Also prevent sharness from adding the unversioned Python scripts to PATH.
Allow overriding the Python version.
Use importing the mercurial module as the test rather than just python,
and merge the python and mercurial module skipping into one test for both
since the mercurial module has to work under the chosen python version.
... since master is picked semi-random (implementation defined) in case
of multiple default branch tips
This mainly affects push mode since a preceding command succeeds
partially (and therefore affect the random), whereas the preceding fails
completely in non-push mode.
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.