From: Wincent Colaiuta <win@wincent.com>
Date: Thu, 22 Nov 2007 10:44:54 GMT
Subject: Re: [PATCH 2/4] Teach git-add--interactive to accept a file path to patch
Message-ID: <887C3CB1-D21B-4143-8D4E-BF37709FA102@wincent.com>
In-Reply-To: <7v8x4q7gns.fsf@gitster.siamese.dyndns.org>

El 22/11/2007, a las 10:50, Junio C Hamano escribió:

> Jeff King <peff@peff.net> writes:
>
>> 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.

Let me explain a little why I started this series. Basically, given  
file "foo" which had multiple changes in it I wanted to stage only  
selected hunks; so I typed:

	git add -i foo

Which of course didn't work. What I wanted to do was jump straight  
into the patch subcommand (hence this series).

If I wanted to add entire files I would have just typed:

	git add foo

So I don't think the proposal to add "-p" (jump to "patch" subcommand)  
and "-a" (jump to "add untracked" subcommand) are a very good idea,  
seeing as we already have builtin-add for adding entire files.

Cheers,
Wincent