On Tue, Apr 2, 2013 at 4:23 PM, Max Horn <m...@quendi.de> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
