Max Horn <max@xxxxxxxxx> writes: [Administrivia: please wrap your lines to reasonable length like 70-75]. > 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. As you mentioned later in your message, I agree that remaining bugs are expected in an initial release. I found that the above phrase is exaggerating, but I think you are over-reacting [*1*]. > 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 ... > ... 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,... Isn't the recent fc/transport-helper-sync-error-fix a reasonable workaround for this issue? The split-head in Hg fundamentally cannot be expressed as a single ref on the Git side, and the series attempts not to trash the marks file when the importer quits abnormally for whatever reason to avoid rendering the resulting repository unusable for future operations, which I thought was the best you could do. > 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. I think your points regarding certain Hg features that do not map well to Git data model are good ones; it would be good to have them at least documented. [Footnote] *1* Personally I think it would have been better if it stopped at somewhere around "some people in the field are using and reporting success, let's give it wider exposure", without using words like "proven", "reliable", or "stable" to make it sound like some objective goodness has already been achieved. People will call the result of the project's work as "proven to be reliable and stable" if it is so; the project does not have to claim and advertise its ware by using such words---the code will prove itself given time, and it is better to let others use these words, not ourselves. -- 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