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? 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. . More work is still
> needed there with both tools, though .
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 .
> 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
> * Renaming a gitifyhg remote just works . Doing that with remote-hg
> triggers a re-clone of the remote repository (if it works at all, I don't
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
Also, unlike remote-hg, which basically passes all the tests of
gitifyhg, gitifyhg barely passes any tests of remote-hg (three).
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