Re: Why doesn't git commit -a track new files

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Feb 25, 2011, 09:03 UTC
Message-ID: <4D677054.9050908@drmicha.warpmail.net>
In-Reply-To: <20110225090126.GA16861@sigill.intra.peff.net>

Jeff King venit, vidit, dixit 25.02.2011 10:01:

Show 37 quoted lines

> On Fri, Feb 25, 2011 at 09:51:37AM +0100, Michael J Gruber wrote:
> 
>>> I assumed that:
>>>
>>>  git commit -a <path>
>>>
>>> would behave more like the "git add -u <path>" case; add new stuff to
>>> the index from <path>, and then commit those changes plus whatever was
>>> already in the index.
>>
>> Yes, you're right. I haven't wrapped my brain completely around those
>> mixed cases yet (changes in index + pathspec argument). My aim is that
>>
>> "git commit <addoptions> <commitoptions> [<pathspec>]"
>>
>> would be equivalent to (the atomic version of)
>>
>> "git add <addoptions> [<pathspec>] && git commit <commitoptions>"
>>
>> and that is difficult because currently, pathspecs are "limiting" for
>> commit and "additive" for add without -u. I mean, I don't want to break
>> anything, at least not before 1.8.0..
> 
> I don't think there is any breakage with "-a" (or "-A") there, as you
> are adding a new mode of operation that currently doesn't work (e.g.,
> right now "git commit -a foo" will die). The only thing that would not
> work is trying to make:
> 
>   git add <path> && git commit
> 
> the same as
> 
>   git commit <path>
> 
> But I am not sure that is a good idea anyway. Yes, it is a little
> inconsistent with the other forms, but I think it is generally what you
> want

Very true. I guess that nails our specification.

> (which is why the default for commit with paths switched from "-i"
> to "-o" long ago).

...before my time (or under my radar).

Equivalent options and slightly different defaults should be fine, just as you explained.

"-i" is implicit for "add" and "-o" is nonsensical/unnecessary (there is no temp. index for add, but there is reset), so those need not be covered.

Michael