Re: [PATCH v2 2/3] remote-helpers: move out of contrib

[Junio C Hamano <gitster@pobox.com>]

Max Horn <max@quendi.de> writes:

[Administrivia: please wrap your lines to reasonable length like 70-75].

> On 21.04.2014, at 22:37, Felipe Contreras <felipe.contreras@gmail.com>
> 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.