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