On Tue, Apr 2, 2013 at 4:23 PM, Max Horn <m...@quendi.de> wrote:
> I'll try to list some of remaining differences, mostly (in my biased opinion)
> improvements on the gitifyhg side. Note that some of these might be outdated
> with felipe's recent changes, i.e. I have not yet had time to review and/or
> test them all. So please bear that in mind.
I've implemented a lot of these, cleaned them up, and pushed them, the
ones that will be integrated:
The ones that won't (at least not without more discussion):
> * added many new test cases, sadly still including some xfails. Several of
> these (both passing and xfailing) also apply to remote-hg (i.e. the issue is
> also present in contrib's remote-hg)
I don't think there's anything inherently better about these tests,
with the compatibility patches here are the results on v0.8 running
session starts ===========================================================
platform linux2 -- Python 2.7.3 -- pytest-2.3.4
collected 80 items
============================================= 5 failed, 66 passed, 9
xfailed in 75.52 seconds =============================================
> * improved handling of hg user names (remote-hg is not able to deal with some
> pathological cases, failing to import commits). Sadly, mercurial allows
> arbitrary strings as usernames, git doesn't...
This is not true; after checking the code, remote-hg can't possibly
fail, if it does, so does gitifyhg. I guarantee it. The only
differences are cosmetic.
That being said, I'll integrate a patch that I believe produces
superior sanitation than gitifyhg's, and passes the gitifyhg test (as
you can see above) (for the most part):
> * failed pushes to hg are cleanly rolled back (using mq.strip() from the mq
> extension), instead of resulting in inconsistent internal state. This is
> quite important in real life, and has bitten me several times with remote-hg
> (and was the initial reason why I switched to gitifyhg). A typical way to
> reproduce this is to push to a remote repository that has commits not yet in
> my local clone.
After the change to force=true, let's see if this happens any more in
remote-hg (Doubt it).
> * git notes are used to associate to each git commit the sha1 of the
> corresponding hg commit, to help users figure out that mapping
I will not integrate this for the moment, there must be a better way
to interact with transport-helper to update these.
> * internally, the marks are using the hg sha1s instead of the hg rev ids. The
> latter are not necessarily invariant, and using the sha1s makes it much
> easier to recover from semi-broken states.
I will investigate the pros and cons of this, but either way it's not
something people are going to immediately need (I doubt the
semi-broken states will happen again).
> * Better handling of various hg errors, see e.g. . More work is still
> needed there with both tools, though .
No idea why something so trivial was mentioned:
> * Support for creating hg tags from git (i.e. pushing light git tags to heavy
> hg tags)
This was already merged to git.git:
(link might change)
> * The gitifyhg test suite is run after each push on Travis CI against several
> git / mercurial combinations .
> In particular, unlike all other remote-hg implementations I know, we
> explicitly promise (and test) compatibility with a specific range of
> Mercurial versions (not just the one the dev happens to have installed right
> now). This has been a frequent issue for me with the msysgit remote-hg
This is nice, but doesn't translate necessarily to anything tangible
for the user. remote-hg, like all git.git, has good development
practices, which minimizes the risks of regressions.
> * Renaming a gitifyhg remote just works . Doing that with remote-hg
> triggers a re-clone of the remote repository (if it works at all, I don't
Changing a remote-hg URL remote just works. Potato potato.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html