On Tue, Apr 2, 2013 at 4:23 PM, Max Horn <max@xxxxxxxxx> wrote: > > On 02.04.2013, at 22:09, John Keeping wrote: > >> On Tue, Apr 02, 2013 at 01:02:49PM -0600, Felipe Contreras wrote: >>> Here is the next round of patches for remote-hg, some which have been >>> contributed through github. >>> >>> Fortunately it seems to be working for the most part, but there are some >>> considerable issues while pushing branches and tags. >> >> How does this compare to the current state of gitifyhg[1]? That's built >> on top of this git-remote-hg script but seems to have been more actively >> developed recently. I only learned about it recently, I've looked at the history and to me it seems rather chaotic, and a lot of the code was simply copied from git-remote-hg without comment. > * 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 ran these test-cases with remote-hg, and the same test-cases pass. I only had to do minor modifications, most of the failures came from subtle differences such as different strategies to sanitize authors, and which branch to pick for HEAD. > * 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... I wouldn't call it improved. In some cases the remote-hg result is better, in others gitifyhg is, but there's only a single case where the author name becomes a significant problem. It's a trivial fix. > * 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. This is not an issue in remote-hg any more since now we force the push. It's not nice, but there's no other way to push multiple bookmarks (aka git branches) to the same branch (aka commit label). I doubt these inconsistent states can happen any more, but if they do, the plan in remote-hg is to simply ignore those revisions, and only push the ones that have git refs. I have the code for that, but I'll not be pushing it to git.git for the time being. > * git notes are used to associate to each git commit the sha1 of the corresponding hg commit, to help users figure out that mapping This is a minor feature. I've had the code for this for quite some time, but for the moment I think there are higher priorities. > * 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 doubt this makes any difference (except for more wasted space). > * Better handling of various hg errors, see e.g. [2]. More work is still needed there with both tools, though [3]. This is literally a three lines fix, and it simply makes one error nicer. Hardly worth mentioning. > * Support for creating hg tags from git (i.e. pushing light git tags to heavy hg tags) remote-hg has the same. > * 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 I've personally checked against multiple versions of Mercurial. It's possible that some error might slip by, but it would get quickly noticed. > * 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). Yeah, now you can change the alias of the remote, but you can't change the remote url. This is not really an advantage, simply an almost imperceptible different choice. I still don't see any good reason why a user might prefer gitifyhg, even more importantly, why gitifyhg developers don't contribute to remote-hg. Also, unlike remote-hg, which basically passes all the tests of gitifyhg, gitifyhg barely passes any tests of remote-hg (three). Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html