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

From: Wincent Colaiuta <win@wincent.com>
Date: Nov 21, 2007, 22:44 UTC
Message-ID: <C6E820C8-91E9-48B2-9219-377CA83163A7@wincent.com>
In-Reply-To: <7vejejfi28.fsf@gitster.siamese.dyndns.org>

El 21/11/2007, a las 21:40, Junio C Hamano escribió:

Show 21 quoted lines

> Jeff King <peff@peff.net> writes:
>
>> ...
>> On top of that, it would be great to be able to do something like
>>
>>  git-add -i *.c
>>
>> and just get prompted for changed files (right now, you only get
>> prompted for changed files, but unchanged files seem to print a  
>> spurious
>> newline).
>>
>> And at any rate, this would require fixing 3/4 to handle the multiple
>> files from git-add.
>>
>> What do you think?
>
> If we are to add path limited behaviour, I think it should also
> grok "git-add -i sub/dir/".  IOW, you would want to have the
> same path selection semantics as git-add without the
> "interactive" bit.

I can work on adding support for dirs as well as files, but am wondering what the desired behaviour is:

- Jeff would like to pass "*.c" and have it only add changed files,  
not unchanged or untracked files

- Junio, do you mean to suggest with your comment that when passing  
untracked files either directly or indirectly (ie. when passing a dir  
containing untracked files) that they should be added (ie. invoked the  
"add untracked" subcommand) in addition to running the "patch"  
subcommand on the changed files?

Of these two approaches, I suspect that the latter would be more "correct", because it would be consistent with the "not interactive" version of git-add.

Cheers, Wincent