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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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