Hi, On Tue, 1 May 2007, Shawn O. Pearce wrote: > Dana How <danahow@xxxxxxxxx> wrote: > > > On 4/30/07, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > > > > >Why not refactor both to use the same implementation and stuff it > > >away in say pack-check.c (for lack of a better place), or start a new > > >file (pack-write.c)? > > > > Actually I didn't just copy it, I tried to rewrite it for my use as > > well as the fast-import.c use (note there is a 3rd copy in some > > *index*.c file which I didn't try to merge in yet). However I didn't > > yet put it in a new file or change fast-import.c to call it since I > > wanted to change as little as possible. > ... > > I agree with all your arguments. I had several reasons > > to avoid extra rearrangements/refactorings: > > (a) First patch to git, not previously known to me; > > (b) I prefer to separate new functionality from "clean-up" work; > > A really good reason. ;-) > > But I'd still rather see it done right the first time, then done > partially (copied) and wait for someone to clean it up later. FWIW it is not just a clean up in the sense of making the code more elegant. It is about catching bugs. The smaller the code base, and the more code is reused for common tasks, the easier it is to - get at bugs, - fix bugs, and - prevent bugs Some might even argue that the elegance of the code is a direct indicator of its quality. Obviously, I am suggesting to go the slightly slower route. In effect, this will turn out to be the faster route, though, since bug fixing traditionally makes up for 90% of development time. Ciao, Dscho - 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