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

From: Michael J Gruber <[email-masked]>
Date: Fri, 25 Feb 2011 09:51:37 +0100

Jeff King venit, vidit, dixit 24.02.2011 17:09:
> On Thu, Feb 24, 2011 at 05:01:55PM +0100, Michael J Gruber wrote:
> 
>>>> - hom. interface: allow "-a pathspec" for commit
>>>
>>> What would it do? It would just behave like "git commit -i
>>> pathspec"?
>>
>> It should do what "-u pathspec" does for add: limit "all tracked" to the
>> pathspec. I know it's the same as without "-a", but why bail out on it?
> 
> Without "-a", we do "git commit -o", which is slightly different with
> respect to stuff in the index.  In the case of:
> 
>   git add -u <path> && git commit
> 
> we will add new changes from <path>, and then commit them along with
> whatever was already in the index.
> 
> With:
> 
>   git commit <path>
> 
> We will commit _just_ the changes in <path>, regardless of what is in
> the index.
> 
> 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've done all the careful planning already, laid out in nice steps. Now
>> it's your time ;)
> 
> Heh. Transitioning to management, I see.

Still in negotiations ;)

> -Peff

Michael