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

From: Jeff King <peff@peff.net>
Date: Feb 25, 2011, 09:01 UTC
Message-ID: <20110225090126.GA16861@sigill.intra.peff.net>
In-Reply-To: <4D676D99.2010600@drmicha.warpmail.net>

On Fri, Feb 25, 2011 at 09:51:37AM +0100, Michael J Gruber wrote:

Show 20 quoted lines

> > 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 (which is why the default for commit with paths switched from "-i" to "-o" long ago).

-Peff