Re: [PATCH 0/4] remote-hg: more improvements

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

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>> It is *way* beyond the quality of any other tool in 'contrib/' and even
>> some tools in the core, like 'git-request-pull' (which has known bugs),
>> and probably even 'git-pt'.
>
> Junio, can you comment on this? I understand this probably doesn't
> really affect the issue at hand, but it'd help clarify if it's ever
> possible to move out of contrib/ nowadays.

I was originally led to believe that its code quality was good
enough, and that was why I merged the bottom three patches of the
series even down to 'next' in the first place.  But after seeing the
"Of course" response that led to [*1*], which made me recall many
patch-review interactions with him, I have started to have doubts.

The code quality of Git that many projects have come to trust their
code with is much more than just "the code at each moment keeps
working for the users as long as the original author is around".
The maintainer of a port to the platform X may lose access to the
platform after switching jobs, the maintainer of a bridge to the
foreign system Y may stop needing to talk to the foreign system
after completing the switch to Git.  Anybody can be hit by a bus,
get sick, or simply lose interest in his past creations.

By reading "git log contrib/remote-helpers" and comparing it with
the logs for the rest of the system, you would realize that the
former would not lead to a quality discussion similar to the one
that led to [*2*], which was only possible because the change was
adequately described to allow anybody to understand the original
issue the change was meant to solve.  The commit that made the
original change made it easy to ask a critical question: "You are
improving B but at the same time breaking A.  Can we do better to
help both A and B?"  And it allowed us to move forward without
having to rob Peter to pay Paul.

Granted, these contrib/ patches were applied with the understanding
that contrib/ stuff can be substandard, because having anything is
often better than having nothing, and you cannot go back in time to
update the history to make these commits more useful to others who
will come later.  But I would be lying if I said that I would expect
that things will suddenly improve and that the codebase will be
maintained for the long haul in a healthy way the minute we move it
out of contrib/ to the core.  Especially after seeing [*1*], which
is just one of the examples that illustrate that there clearly is no
will to explain the changes to help others who come later to help
maintaining the code.  "I'll take good care of the codebase", "I've
spend the time to make it better", "Me, me, me", is not what the
open source process is about.


[References]

*1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341
*2* http://thread.gmane.org/gmane.comp.version-control.git/248075/focus=248204