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

[Marco <netuse@lavabit.com>]

On 2011-02-24 Junio C Hamano <gitster@pobox.com> wrote:

> > I don't understand why there's not switch (is there?) for commit to
> > commit new and deleted files, like -A for git add?
> 
> Historical accident.  In the early days of git, there was no .gitignore
> mechanism, so a mode that operates on everything under the working tree
> was almost always an undesired thing to have (think *.o files).
> 
> Then .gitignore mechanism came, and "add ." has become usable.  But
> "commit -a" has been widely used way before that.
> 
> If you look at "commit -a" within that context, you would understand why
> it should only look at the paths git knows about.
> 
> Of course, "add -A" is a much later invention.  The option was named "-A"
> with capital letter, even though there is no "add -a".
> 
> This was because I knew we would eventually want to have "commit -A" that
> grabs everything and new files (honoring the gitignore mechanism), and
> aimed for consistency between "add -A" that I was adding, and "commit -A"
> that was yet to be written.  See 3ba1f11 (git-add --all: add all files,
> 2008-07-19).
> 
> I think it now is sensible to add "commit -A" if somebody is inclined to
> do so.  Nobody felt the need for it strongly enough to do so, it seems.

Thank you for the detailed explanation.

To sum this up: -A would be a nice-to-have feature but it's not necessary to
implement since we have add -A. But if I'm willing to implement it myself I'm
free to do that.


Regards
Marco