Re: [PATCH 4/8] git-repack --max-pack-size: add fixup_header_footer()

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 1, 2007, 07:32 UTC
Message-ID: <Pine.LNX.4.64.0705010927240.29859@racer.site>
In-Reply-To: <20070501060340.GD5942@spearce.org>

Hi,

On Tue, 1 May 2007, Shawn O. Pearce wrote:

Show 23 quoted lines

> Dana How <danahow@gmail.com> wrote:
>
> > On 4/30/07, Shawn O. Pearce <spearce@spearce.org> 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