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

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Dec 15, 2012, 07:09 UTC
Message-ID: <50CC2244.4040103@alum.mit.edu>
In-Reply-To: <CAMP44s0r_KAKt7Lm1cdumN1cOWzjab3ruYqxp-s6OR1g1qqbcQ@mail.gmail.com>

On 12/15/2012 04:14 AM, Felipe Contreras wrote:

Show 13 quoted lines

> 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/