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

=========================================================== test
session starts ===========================================================
platform linux2 -- Python 2.7.3 -- pytest-2.3.4
collected 80 items

test/test_author.py ........F
test/test_clone.py ......xx.........x...x..
test/test_notes.py ..Fx.
test/test_pull.py ....x..xx..
test/test_push.py ..........F...x........FF...
test/test_special_cases.py ...

============================================= 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. [2]. More work is still 
> needed there with both tools, though [3].

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 [4].
> 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 [5]. Doing that with remote-hg 
> triggers a re-clone of the remote repository (if it works at all, I don't 
> remember).

Changing a remote-hg URL remote just works. Potato potato.


Felipe Contreras
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

Reply via email to