On 21.04.2014, at 22:37, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > The remote-helpers in contrib/remote-helpers have proved to work, be > reliable, and stable. It's time to move them out of contrib, and be > distributed by default. Really? While I agree that git-remote-hg by now works quite well for basic usage in simple situation, there are still unresolved bugs and fundamental issues with it. E.g. I recently showed you a reproducible use case involving git-remote-hg that puts the helper into a broken state from which it is difficult for a normal user to recover. Namely when a hg branch has multiple heads, then git-remote-hg exports all of those to git, but only adds a git ref for one of them; after pruning unreferenced commits, the fast-import marks file references git commits that now are missing, prompting git fast-import to crash and trash the marks file. Afterwards, attempts to push or pull from the remote hg repository are answered with an error. There are other ways to trigger variants of this, and these are not artificial, they occur in real life (this is how I run into the issue). There are more issues related to unresolved clashes between the git and hg ways of naming things. E.g. I am collaborating on a hg repository that has branches "foo" and "foo/bar" which git-remote-hg cannot handle because it translates them to git branch names, and, well, git cannot handle that. It may be hard to deal with some of them, and admittedly I wouldn't necessarily expect that all of these are handled from the outset, i.e. "in version 1.0". But I think at the very least, users should be warned about these things. More broadly speaking, there is currently no documentation at all in git.git for those remote helpers, which I find worrisome. That said, I don't know what the criteria are for moving something out of contrib. Perhaps it is OK to move an undocumented remote-helper with known bugs out of contrib. Cheers, Max
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail