From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Thu, 24 Feb 2011 15:54:02 GMT
Subject: Re: Why doesn't git commit -a track new files
Message-ID: <4D667F1A.5060408@drmicha.warpmail.net>
In-Reply-To: <20110224154908.GA29309@sigill.intra.peff.net>

Jeff King venit, vidit, dixit 24.02.2011 16:49:
> On Thu, Feb 24, 2011 at 04:02:15PM +0100, Michael J Gruber wrote:
> 
>> "commit -A" does not exist, so that "git add -A && git commit" is your
>> only way.
>>
>> [...]
>>
>> Also, "-A" supports a very "un-gitty" way of using git. This makes it
>> unlikely that someone cares to implement it... (By "un-gitty" I don't
>> mean a matter of personal taste, but a matter of fruitful habits.)
> 
> Actually, I would find "git commit -A" useful. Not as part of my normal
> project workflow, but would be a great shorthand for one-off debuggings
> (e.g., "echo content >>file && git commit -A -m msg", which Just Works
> whether it is the first or a later commit).
> 
> But as you mentioned, it is sadly not as trivial as just adding a new
> way to call "git add". So I think nobody has simply cared enough to
> implement it to date.

How about this program:

- refactor add, commit to share the "add parts"
- homogenize interface: replace "add -u" by "add -a" (hidden
compatibility thingy of course)
- hom. interface: allow "-a pathspec" for commit
- have commit -A

Oh, and do "commit -n" what one would expect [1.8.0] :)

Michael