git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Max Horn <max@quendi.de>
Date
Apr 2, 2013, 22:23 UTC
Message-ID
<2670C2C0-E30F-47DA-8901-899FEE11059E@quendi.de>
In-Reply-To
<20130402200948.GF2222@serenity.lan>
On 02.04.2013, at 22:09, John Keeping wrote:
Show 10 quoted lines
> 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.
Several bugs that were fixed in gitifyhg some time ago are now fixed in this remote-hg, too.
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.
* 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)
* 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...
* 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.
* git notes are used to associate to each git commit the sha1 of the corresponding hg commit, to help users figure out that mapping
* 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.
* Better handling of various hg errors, see e.g. [2]. More work is still needed there with both tools, though [3].
* Support for creating hg tags from git (i.e. pushing light git tags to heavy hg tags)
* 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
* 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). 
Sadly, while working on gitifyhg, we discovered various more design problems (from our perspective, at least) in Mercurial, e.g. the fact that commits are not necessarily normalized, in the sense that "equivalent" commits (same author, time, changed files / code) can have different hashs, with some nasty implications for import. This is potentially problematic because without extra care, these would be mapped to the same commit on the git side.
Unfortunately, we also stumbled into various problems with the git remote-helper system. We are currently using the fast-import remote-helper type, but are encountering more and more of its limitations. This affects remote-hg and gitifyhg equally, and probably other remote helpers. E.g. "git push --dry-run" seems to be impossible to support with such a remote-helper (but then I might be mistaken).
Thing is, for several of these I don't feel quite competent enough to come up with patches that I could submit here. And in my experience just reporting a perceived problem with the remote-helper API is not going to trigger a response here [6]. I guess that's why we stopped reporting them here for now, but if there is interest I could try to compile an overview.

[1] https://github.com/buchuki/gitifyhg [2] https://github.com/buchuki/gitifyhg/commit/74b71f4 [3] https://github.com/buchuki/gitifyhg/issues/66 [4] https://travis-ci.org/buchuki/gitifyhg/builds [5] https://github.com/buchuki/gitifyhg/commit/68ce89bb32 [6] http://thread.gmane.org/gmane.comp.version-control.git/214802

Previous: John KeepingNext: Felipe Contreras
Message 24 of 48 in “remote-hg: general updates”
  1. 00/13 remote-hg: general updatesFelipe Contreras, Apr 2, 2013
  2. 01/13 remote-hg: trivial cleanupsFelipe Contreras, Apr 2, 2013
  3. 02/13 remote-hg: add missing config variable in docFelipe Contreras, Apr 2, 2013
  4. 03/13 remote-hg: properly report errors on bookmark pushesFelipe Contreras, Apr 2, 2013
  5. 04/13 remote-hg: fix for files with spacesFelipe Contreras, Apr 2, 2013
  6. 05/13 remote-hg: make sure fake bookmarks are updatedFelipe Contreras, Apr 2, 2013
  7. 06/13 remote-hg: trivial test cleanupsFelipe Contreras, Apr 2, 2013
  8. 07/13 remote-hg: redirect buggy mercurial outputFelipe Contreras, Apr 2, 2013
  9. Junio C HamanoApr 2, 2013
  10. Felipe ContrerasApr 2, 2013
  11. Junio C HamanoApr 2, 2013
  12. Felipe ContrerasApr 4, 2013
  13. Junio C HamanoApr 4, 2013
  14. 08/13 remote-hg: split bookmark handlingFelipe Contreras, Apr 2, 2013
  15. 09/13 remote-hg: refactor exportFelipe Contreras, Apr 2, 2013
  16. 10/13 remote-hg: update remote bookmarksFelipe Contreras, Apr 2, 2013
  17. 11/13 remote-hg: force remote pushFelipe Contreras, Apr 2, 2013
  18. 12/13 remote-hg: don't update bookmarks unnecessarilyFelipe Contreras, Apr 2, 2013
  19. 13/13 remote-hg: update tags globallyFelipe Contreras, Apr 2, 2013
  20. Junio C HamanoApr 2, 2013
  21. Felipe ContrerasApr 2, 2013
  22. Junio C HamanoApr 2, 2013
  23. John KeepingApr 2, 2013
  24. Max HornApr 2, 2013
  25. Felipe ContrerasApr 3, 2013
  26. Felipe ContrerasApr 3, 2013
  27. Antoine PelisseApr 3, 2013
  28. Felipe ContrerasApr 5, 2013
  29. Max HornApr 4, 2013
  30. Felipe ContrerasApr 4, 2013
  31. Felipe ContrerasApr 4, 2013
  32. Max HornApr 4, 2013
  33. Felipe ContrerasApr 4, 2013
  34. Max HornApr 5, 2013
  35. Felipe ContrerasApr 6, 2013
  36. Philip OakleyApr 6, 2013
  37. Felipe ContrerasApr 6, 2013
  38. Junio C HamanoApr 6, 2013
  39. Felipe ContrerasApr 6, 2013
  40. Junio C HamanoApr 7, 2013
  41. Jed BrownApr 4, 2013
  42. Junio C HamanoApr 4, 2013
  43. Jed BrownApr 4, 2013
  44. Felipe ContrerasApr 4, 2013
  45. Felipe ContrerasApr 4, 2013
  46. Jed BrownApr 4, 2013
  47. Felipe ContrerasApr 4, 2013
  48. Felipe ContrerasApr 5, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.