Philippe Vaucher <philippe.vaucher@xxxxxxxxx> 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 -- 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