Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

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
expected.

* 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.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/