This was crafted mostly via a bunch of aimless flailing in the
code. I'm pretty well convinced at this point that the incoming
support needs to be rewritten slightly to behave properly in the new
world order (specifically, the overlayrepo class probably should be
subclassing localrepo, or else more directly reimplementing things
instead of trying to forward methods.)
I've been waiting for dulwich upstream to fix this *and* for a test
from domruf that's acceptable. Having gotten neither over a period of
/months/, and having hit the bug myself, I'm moving on and accepting a
patch without tests. This will likely break again, but hopefully
before we'd break it dulwich will be fixed.
Previously, we emitted every Git tree when updating between Mercurial
changesets. With this patch, we now only emit Git trees that changed. A
side-effect of the implementation is that we now only update in-memory
Git trees objects that changed. Before, we always touched Git trees,
invalidating them in the process and causing Dulwich to recalculate
their SHA-1. Profiling revealed this to be expensive and removing the
extra calculation shows a nice performance win.
Another optimization is to not sort the order that changed paths are
processed in. Previously, we sorted by length, longest to shortest.
Profiling revealed that the sorts took a non-trivial amount of time.
While sorted execution resulted in likely idempotent behavior, it
shouldn't be strictly required.
On the author's machine, conversion of the Mercurial repository itself
decreased from ~493s to ~333s. Even more impressive is conversion of
Firefox's main repository (which is considerably larger). Converting the
first 200 revisions of that repository decreased from ~152s to ~42s.
This replaces the brute force Mercurial to Git export with one that is
incremental. It results in a decent performance win and paves the road
for parallel export via using multiple incremental exporters.
If dulwich is presented with a "sub minute" timezone offset, it throws
an exception (see tests/test-timezone.t). This patch rounds the timezone
down to the next minute before passing the value to dulwich.
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
This isn't a real implementation of phases support. Rather, it's just enough
to avoid the traceback.
Traceback (most recent call last):
File "/usr/local/share/python/hg", line 38, in <module>
mercurial.dispatch.run()
File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 28, in run
sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 65, in dispatch
return _runcatch(req)
File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 88, in _runcatch
return _dispatch(req)
File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 741, in _dispatch
cmdpats, cmdoptions)
File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 514, in runcommand
ret = _runcommand(ui, options, cmd, d)
File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 831, in _runcommand
return checkargs()
File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 802, in checkargs
return cmdfunc()
File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 738, in <lambda>
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
File "/usr/local/lib/python2.7/site-packages/mercurial/util.py", line 472, in check
return func(*args, **kwargs)
File "/usr/local/lib/python2.7/site-packages/mercurial/commands.py", line 3942, in incoming
return hg.incoming(ui, repo, source, opts)
File "/usr/local/lib/python2.7/site-packages/mercurial/hg.py", line 525, in incoming
return _incoming(display, subreporecurse, ui, repo, source, opts)
File "/usr/local/lib/python2.7/site-packages/mercurial/hg.py", line 494, in _incoming
displaychlist(other, chlist, displayer)
File "/usr/local/lib/python2.7/site-packages/mercurial/hg.py", line 524, in display
displayer.show(other[n])
File "/usr/local/lib/python2.7/site-packages/mercurial/cmdutil.py", line 670, in show
self._show(ctx, copies, matchfn, props)
File "/usr/local/lib/python2.7/site-packages/mercurial/cmdutil.py", line 691, in _show
label='log.changeset changeset.%s' % ctx.phasestr())
File "/usr/local/lib/python2.7/site-packages/mercurial/context.py", line 203, in phasestr
return phases.phasenames[self.phase()]
File "/usr/local/lib/python2.7/site-packages/mercurial/context.py", line 201, in phase
return self._repo._phasecache.phase(self._repo, self._rev)
AttributeError: 'overlaychangectx' object has no attribute '_repo'
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.
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.
This change wraps hg.peer to allow for capturing the repo object. It is then
passed in to new gitrepo instanceds. This will be needed to implement later
functionality, such as richer bookmark support using pushkeys.
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.
Mercurial has support for including information about the tested versions of
Mercurial for an extension when it detects that an extension has broken. This
change includes the appropriate attribute in the extension.
Mercurial has support for including a link to an issue tracker when it detects
that an extension has broken. This change includes the appropriate attribute
in the extension, pointing it at the issue tracker for the main BitBucket repo.
There was a bug introduced in fa5f235be2cd such that calling hg outgoing on
a Git repository would result in all refs being deleted from the remote
repository (with the possible exception of the currently checked out branch).
It wasn't noticed before because the existing test for outgoing didn't actually
verify the refs on the remote. This changeset fixes the bug, as well as adding
test coverage to allow verifying that the fix works.
When exporting Git commits, verify that the tree and parents objects
exist in the repository before allowing the commit to be exported. If a
tree or parent commit is missing, then the repository is not valid and
the export should not be allowed.
