Re: [PATCH 00/13] remote-hg: general updates

[Felipe Contreras <felipe.contreras@gmail.com>]

On Tue, Apr 2, 2013 at 4:23 PM, Max Horn <max@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:
http://github.com/felipec/git/tree/fc/remote/hg-next

The ones that won't (at least not without more discussion):
http://github.com/felipec/git/tree/fc/remote/hg-gitifyhg-compat

> * 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
remote-hg:

=========================================================== 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):

https://github.com/felipec/git/commit/c0e363915eb6459233e37d5082fb2ff7c7c727b4

> * 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

Easy:
https://github.com/felipec/git/commit/2294fb445f5c018a39f421cba70e4d8510c04c89

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:
https://github.com/felipec/git/commit/d12e35d23b9d26d384c3dbbce25a09720ccbceff

> * Support for creating hg tags from git (i.e. pushing light git tags to heavy hg tags)

This was already merged to git.git:
https://git.kernel.org/cgit/git/git.git/commit/?id=32f370f62177b505daf96aaf711c0249d881b6c0

(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.

Cheers.

-- 
Felipe Contreras