[PATCH 0/3] git-add--interactive: use --recount, editing

From: Thomas Rast <trast@student.ethz.ch>
Date: Jul 2, 2008, 21:58 UTC
Message-ID: <1215035909-26110-1-git-send-email-trast@student.ethz.ch>
In-Reply-To: <7v7ic4hmj5.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

Show 6 quoted lines

> 
> I recall that the original "add--interactive" carefully counted numbers in
> hunks it reassembles (as it can let you split and then you can choose to
> use both parts, which requires it to merge overlapping hunks back), but if
> you are going to use --recount anyway, perhaps we can discard that logic?
> It may make the patch application less robust, though.  I dunno.

This series takes it a bit further. I played around with 'apply', and it seems there is no reason to even merge the hunks. (It would be great if someone who knows builtin-apply.c could confirm this.) So we can get rid of all recounting except for the correct splitting boundaries. These are the first two patches.

Junio C Hamano wrote:

Show 7 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > I wonder why bother trying to import things when you do not need them to 
> > begin with!  I mean, it is _obvious_ that in this case, we want .git/ to 
> > be writable _anyway_, so why not stick with a fixed name in that?
> 
> Good suggestion -- I love that simplicity.  Thomas?

Well, changed that back.

Apart from that, no real changes to 3/3, but the $needs_recount code has become unnecessary because 1/3 already forces --recount.

- Thomas

 Documentation/git-add.txt  |    1 +
 git-add--interactive.perl  |  203 ++++++++++++++++++++++---------------------
 t/t3701-add-interactive.sh |   67 +++++++++++++++
 3 files changed, 172 insertions(+), 99 deletions(-)