It is unclear to me why we keep a file (which can become out of sync) of remote
refs instead of just using dulwich. This caught a missing remote ref in the
test suite.
See inline comments for why the additional metadata needs to be stored.
This literally breaks all the hashes because of the additional metadata. The
changing of hashes is unfortunate but necessary to preserve bidirectionality.
While this could be broken up into multiple commits, there was no way to do
that while preserving bidirectionality. Following the principle that every
intermediate commit must result in a correct state, I decided to combine the
commits.
This is quite similar to syntax Git supports. In the future maybe core
Mercurial could be extended to support this, but I think this independently
makes sense in hg-git.
The usage of getattr was unsafe. Use hgutil.safehasattr instead.
util.safehasattr has been around since Mercurial 2.0.
This also fixes the formerly disabled test in test-pull.t.
Previously we'd attempt to import every single reachable commit in the Git
object store.
The test adds another branch to the Git repo and doesn't import it until much
later. Previously we'd import it when we ran `hg -R hgrepo pull -r beta`. Now
we won't.
The return value as implemented in git_handler.fetch was pretty bogus. It used
to return the number of values that changed in the 'refs/heads/' namespace,
regardless of whether multiple values in there point to the same Mercurial
commit, or whether particular heads were even imported. Fix all of that by
using the actual heads in the changelog, just like vanilla Mercurial.
The test output changes demonstrate examples where the code was buggy.
One or both of these requirements were in almost every test in exactly the same
way. Now, these checks are performed in every test that uses the testutil.
This makes it easier for test authors to add these checks into new tests (just
add a reference to the testutil, which you'd probably want anyway).
We considered having each test declare their requirements (currently, either
"git" or "dulwich"), but in this case, preferred the simplicity of having the
check always performed (even if a particular test doesn't need one or the
other). You can't perform any meaningful testing of Hg-Git without both of
these dependencies properly configured. The main value to checking for them
in the tests (rather than just letting the tests fail) is that it gives a
meaningful error message to help people figure out how to fix their environment.
In the case that either git or dulwich is missing, the information will be
just as clearly conveyed regardless of whether its all the tests that are
skipped, or just most of them.
I didn't add dulwich to hghave (even though this is clearly the sort of thing
that hghave is intended for) because hghave is currently pulled from Mercurial
completely unchanged, and it's probably best to keep it that way.
Tested by running the tests in three configurations:
* No dulwich installed (ran 0, skipped 28, failed 0, output:
Skipped *: missing feature: dulwich)
* Bad git on path (ran 1, skipped 27, failed 0, output:
Skipped *: missing feature: git command line client)
* Working git and correct version of dulwich installed
(ran 28, skipped 0, failed 0)
Thanks to Felipe Contreras for the idea to extract this logic into a library.
Thanks to Felipe Contreras for the patch which this was based on.
The functions were renamed to make it clearer that these are shell functions
rather than normal git/hg commands, and to make it clearer which tool is being
invoked.
Old name | New name
------------------------
commit | fn_git_commit
tag | fn_git_tag
hgcommit | fn_hg_commit
hgtag | fn_hg_tag
Extraction from test-encoding.t was left for a subsequent patch, as I was seeing
unexpected output changes when I attempted the extraction.
The gitcommit and hgcommit functions in test-bookmark-workflow.t were left
as-is for now, as they have a different behavior than the standard version
(separate counters for each).
Thanks to Felipe Contreras for the patch which this was based on.
Even though the MQ extension was only used in a single test
(test-pull-after-strip.t), I included it in the testutil. It shouldn't hurt
anything to have it enabled and not used, and saves us from having to deal
with enabling extensions in individual tests at all.
Similarly, this changeset results in the graphlog extension being enabled
for all tests, even though there were some that didn't use it before. This is
even less significant in Mercurial 2.3+, since in those versions, graphlog is
part of core, and is available even when the extension is disabled.
This should fix a bug introduced by 4f4ab2d which caused all tags to be
duplicated as bookmarks on pull.
Test coverage has been added for pull to allow verifying the fix.
Dulwich now supports local repositories just fine. Not using the daemon makes
the tests easier to read and more reliable (less likely to be skipped because
a stray daemon is holding onto the port).
In many cases we were piping to a python script to strip out the varying leading
path to the test repos. This is no longer needed, as the modern run-test.py
automatically substitutes the leading path as $TESTTMP. Eliminating the piping
makes the tests easier to read and write, as well as allowing the exit codes
to be verified by the test.
