On 12/15/2012 04:14 AM, Felipe Contreras wrote:
> I'm going to say it one last time; merging this patch series either
> creates issues for the users, or not. There is a reality out there,
> independent of what you, Junio, or me think or say. And the fact is,
> that if this patch series is going to create issues for the users,
> *nobody* has pointed out why, so, since there's no evidence for it,
> the only rational thing to do is believe that there will be no issues
> for the users.
> There is no known issue with the code, that is a fact. This code could
> be easily merged today, and in fact, it was merged by Junio already
> (but then reverted). There are no positive outcomes from the delay,
> only negative ones. I will address the minute issue about the extra
> cruft, eventually.
Cruft in the codebase is a problem for git *developers* because it makes
the code harder to maintain and extend.
And therefore cruft is a problem for git *users* because it slows down
future development (in whatever small amount).
Moreover, it is dangerous for a project to accept crufty code based on a
contributor's promise to clean up the code later:
* The developer might not get around to it, or might take longer than
* Until it is cleaned up, the cruft hinders other potential developers
to that code.
* The presence of cruft lowers the expectation of quality for the whole
project; cruft breeds more cruft.
It is simpler and fairer to have a policy "no crufty code" than to try
to evaluate each instance on a case-by-case basis.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html