Re: [PATCH 2/4] Teach git-add--interactive to accept a file path to patch

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 22, 2007, 09:50 UTC
Message-ID: <7v8x4q7gns.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20071122091356.GD7153@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> On Wed, Nov 21, 2007 at 04:18:57PM -0800, Junio C Hamano wrote:
>
>> What I meant was that if "git add -i" (unrestricted) shows paths
>> from a set A, "git add -i paths..." should show paths from a
>> subset of the set A and that subset should be defined with the
>> existing ls-files pathspec semantics.
>
> Ah, I think that is definitely the right behavior. But it does raise one
> more question: is going right into the 'add hunk' interface the correct
> behavior, or is that an orthogonal issue?

I am moderately negative about "paths imply jump to patch subcommand". An option to git-add--interactive that tells which subcommand to initially choose is probably acceptable, though.

Would the patch I just sent out (you need to assemble the parts) make things easier?