As pointed out by l33t, Hg-Git's output for push doesn't currently do a very
good job of telling the user what happened. My previous changes in this area
had moved some of the output from status to note, making it only show if
--verbose was specified. However, I hadn't realized at the time that the
reference information (though overly verbose) was providing a valueable purpose
that otherwise wasn't met; telling the user that a remote reference had changed.
This changeset makes it so that:
* default output will include simple messages like "adding reference
refs/heads/feature" and "updating reference refs/heads/master" (omitting any
mention of unchanged references)
* verbose output will include more detailed messages like "adding reference
default::refs/heads/feature => GIT:aba43c" and "updating reference
default::refs/heads/master => GIT:aba43c" (omitting any mention of unchanged
references)
* debug output will include the detailed output like in verbose, but
addtionally will include messages like "unchanged reference
default::refs/heads/other => GIT:aba43c"
https://bitbucket.org/durin42/hg-git/issue/64/push-confirmation
l33t pointed out that currently, Hg-Git doesn't provide any confirmation that a
push was successful other than the exit code. Normal Mercurial provides a
couple other messages followed by "added X changesets with Y changes to
Z files". After this change, Hg-Git will provide much more similar output.
It's not identical, as the underlying model is substantially different, but the
concept is the same. The main message is "added X commits with Y trees and
Z blobs".
This change doesn't affect the output of what references/branches were touched.
That will be addressed in a subsequent commit.
Dulwich doesn't provide an easy hook to get the information needed for this
output. Instead of passing generate_pack_contents as the pack generator
function to send_pack, I pass a custom function that determines the "missing"
objects, stores the counts, and then calls generate_pack_contents (which then
will determine the "missing" objects again.
The new expected output:
searching for changes # unless quiet true
<N> commits found # if verbose true
list of commits: # if debugflag true and at least one commit found
<each hash> # if debugflag true and at least one commit found
adding objects # if at least one commit found unless quiet true
added <N> commits with <N> trees and <N> blobs # if at least one object unless
# quiet true
https://bitbucket.org/durin42/hg-git/issue/64/push-confirmation
Now that we're in the unified test format, there isn't a need to use echo
to provide context to command output. This technique actually ends up resulting
in redundant output. To preserve the original context, but eliminate the
redundancy, such echo statements have been converted into comment lines.
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.
It's functionally equivalent to create a directory, cd into it, git init, and
cd out of the directory, or simply git init with the directory specified.
In several cases, we were doing the former without performing any other
operations in the git repo, which just made the test unneccesarily complex.
Even in the case where we still want to cd into the directory, calling git
init with the directory name eliminates the need for a separate mkdir command.
This changeset converts the former approach to the latter with the goal of
increasing the readability of the tests.
Thanks to Felipe Contreras for the patch which this was based on.
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.
When communicating with the user on push/outgoing, Mercurial doesn't show a
"exporting hg objects to git" message, so we shouldn't. The message has been
changed to be shown if --verbose is specified.
When communicating with the user on push, Mercurial doesn't show much on
success. Currently, Hg-Git shows every changed ref. After this change,
the default output will more closely match Mercurial's regular behavior (no
per-ref output), while changed refs will be shown if --verbose is specified,
and all refs will be shown if --debug is specified.
This changeset adds test coverage for comparing "hg outgoing -B" in normal
Mercurial usage with Hg-Git usage. This didn't match, since previously, gitrepo
didn't provide a meaningful listkeys implementation. Now, it does.
gitrepo now has access to a GitHandler when a localrepo is available. This
handler is used to access the information needed to implement listkeys for
namespaces (currently, only bookmarks) and bookmarks.
A couple of other tests were testing "divergent bookmark" scenarios. These
tests have been updated to filter out the divergent bookmark output, as it isn't
consistent across the supported Mercurial versions.
In the logic that was attempting to handle the case where the local repo doesn't
have any bookmarks, the assumption was being made that tip resolved to a
non-null revision. In the case of a totally empty local repo, however, that
isn't a valid assumption, and resulted in attempting to set the master ref
to None, which broke dulwich.
The "fix", which avoids the traceback and allows the push to complete (though
still do nothing, since in this case there aren't any changes to push), is to
not tweak the refs at all if tip is nullid. Leaving the special capabilities
ref and not adding a master ref appears to be fine in this case.
The output for "hg push" when there were no changes didn't quite match between
Mercurial with and without Hg-Git, so I changed the behavior to bring it into
synch. The existing "creating and sending data" message was changed to be
included if --verbose is specified.
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.
