Why doesn't git commit -a track new files

Why doesn't git commit -a track new files

[Marco]

Hi,

I'm new to git and a bit confused about how some commands work.

git add .                    -- Adds everything *but* deleted files
git add -A                   -- Adds everything
git commit -a -m "whatever"  -- Commits everything *but* new files

I don't understand why there's not switch (is there?) for commit to commit new
and deleted files, like -A for git add? Is the only thing to do this sth like

git add -A && git commit -m "Message"


Marco

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

[Ævar Arnfjörð Bjarmason]

On Thu, Feb 24, 2011 at 11:22, Marco <netuse@lavabit.com> wrote:
> I'm new to git and a bit confused about how some commands work.
>
> git add .                    -- Adds everything *but* deleted files
> git add -A                   -- Adds everything
> git commit -a -m "whatever"  -- Commits everything *but* new files
>
> I don't understand why there's not switch (is there?) for commit to commit new
> and deleted files, like -A for git add? Is the only thing to do this sth like
>
> git add -A && git commit -m "Message"

You mean commit things you deleted, and untracked files?

That's a good question actually. It would be useful in some cases.

I've scripted around that a few times, maybe a switch for that would be useful.

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

[Pascal Obry]

Marco,

> I don't understand why there's not switch (is there?) for commit to commit new
> and deleted files, like -A for git add? Is the only thing to do this sth like
>
> git add -A && git commit -m "Message"

Never had the need for this. The reason is maybe when you are trying to have
a small set if incremental commits, you usually don't want to add everything but
you review the change carefully with "git add -p". Now in some circumstances
it could probably be useful.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

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

[Marco]

On 2011-02-24 Pascal Obry <pascal@obry.net> wrote:

> Marco,
> 
> > I don't understand why there's not switch (is there?) for commit to
> > commit new and deleted files, like -A for git add? Is the only thing to
> > do this sth like
> >
> > git add -A && git commit -m "Message"
> 
> Never had the need for this. The reason is maybe when you are trying to have
> a small set if incremental commits, you usually don't want to add
> everything but you review the change carefully with "git add -p".

Of course not as default behaviour. Just as a switch (e.g. -A). If one wishes
this behaviour one can use it. Nobody forces you to use it (like -a).

> Now in some circumstances it could probably be useful.

Yes.


Marco

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

[Michael J Gruber]

Marco venit, vidit, dixit 24.02.2011 11:22:
> Hi,
> 
> I'm new to git and a bit confused about how some commands work.
> 
> git add .                    -- Adds everything *but* deleted files
> git add -A                   -- Adds everything
> git commit -a -m "whatever"  -- Commits everything *but* new files
> 
> I don't understand why there's not switch (is there?) for commit to commit new
> and deleted files, like -A for git add? Is the only thing to do this sth like
> 
> git add -A && git commit -m "Message"

"commit -a" is much like "add -u", at least when used without file
arguments ("pathspec").

"commit -A" does not exist, so that "git add -A && git commit" is your
only way.

Why does it not exist? Because you should at least
"git add -A && git status && behappy && git commit".

The middle part of that line could be done in the editor which commit
invokes, of course.

>From the technical side: git-add and git-commit share surprsingly little
code (the "add" part of commit is not shared). So, implementing it
wouldn't simply be a different "add call" from commit.

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.)

Michael

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

[Jeff King]

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.

-Peff

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

[Michael J Gruber]

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

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

[Jeff King]

On Thu, Feb 24, 2011 at 04:54:02PM +0100, Michael J Gruber wrote:

> > 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"

Sounds good.

> - homogenize interface: replace "add -u" by "add -a" (hidden
> compatibility thingy of course)

I like it.

> - hom. interface: allow "-a pathspec" for commit

What would it do? It would just behave like "git commit -i pathspec"?

> - have commit -A

Sounds good.

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

Yeah, I like that, too.

Are you volunteering to work on it all? :)

-Peff

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

[Michael J Gruber]

Jeff King venit, vidit, dixit 24.02.2011 17:00:
> On Thu, Feb 24, 2011 at 04:54:02PM +0100, Michael J Gruber wrote:
> 
>>> 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"
> 
> Sounds good.
> 
>> - homogenize interface: replace "add -u" by "add -a" (hidden 
>> compatibility thingy of course)
> 
> I like it.
> 
>> - 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?

> 
>> - have commit -A
> 
> Sounds good.
> 
>> Oh, and do "commit -n" what one would expect [1.8.0] :)
> 
> Yeah, I like that, too.
> 
> Are you volunteering to work on it all? :)

I've done all the careful planning already, laid out in nice steps. Now
it's your time ;)

OK, I'll do "-n".

Michael

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

[Matthieu Moy]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Why does it not exist? Because you should at least
> "git add -A && git status && behappy && git commit".

There are alternatives like

git status && behappy && git commit -A

or

git commit -A && look at status $EDITOR && behapy && save

> Also, "-A" supports a very "un-gitty" way of using git. This makes it
> unlikely that someone cares to implement it...

I guess that's it. It's not usefull to most Git developers, hence nobody
cared to implement it. But IIRC the switch "add -A" was chosen partly
because -A didn't exist for commit, hence this leaves room for commit
-A.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Michael J Gruber]

Matthieu Moy venit, vidit, dixit 24.02.2011 17:04:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> Why does it not exist? Because you should at least
>> "git add -A && git status && behappy && git commit".
> 
> There are alternatives like
> 
> git status && behappy && git commit -A

That may not give the full picture of untracked stuff in subdirs.

> or
> 
> git commit -A && look at status $EDITOR && behapy && save

Yes, I even mentioned that, but you cut it. Bad bad boy! ;)

>> Also, "-A" supports a very "un-gitty" way of using git. This makes it
>> unlikely that someone cares to implement it...
> 
> I guess that's it. It's not usefull to most Git developers, hence nobody
> cared to implement it. But IIRC the switch "add -A" was chosen partly
> because -A didn't exist for commit, hence this leaves room for commit

Yes.

So, we have one more volunteer for the plan just laid out, right?

Michael

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

[Jeff King]

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.

> I've done all the careful planning already, laid out in nice steps. Now
> it's your time ;)

Heh. Transitioning to management, I see.

-Peff

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

[Marc Weber]

I'd not change behaviour of
git commit -a

introducing 

git commit -A behaving like git add -A && git commit would be fine.

Marc Weber

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

[Marco]

On 2011-02-24 Michael J Gruber <git@drmicha.warpmail.net> wrote:

> > git status && behappy && git commit -A
> 
> That may not give the full picture of untracked stuff in subdirs.

May I ask why not? AFAIK git status outputs staged and untracked stuff.

> > git commit -A && look at status $EDITOR && behapy && save
> 
> Yes, I even mentioned that, but you cut it. Bad bad boy! ;)
> 
> >> Also, "-A" supports a very "un-gitty" way of using git. This makes it
> >> unlikely that someone cares to implement it...

I think it *can* be used in an appropriate manner.
BTW: Why isn't commit -a »un-gitty«?


Marco

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

[Junio C Hamano]

Marco <netuse@lavabit.com> writes:

> I'm new to git and a bit confused about how some commands work.
>
> git add .                    -- Adds everything *but* deleted files
> git add -A                   -- Adds everything
> git commit -a -m "whatever"  -- Commits everything *but* new files
>
> 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.

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

[Marco]

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

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

[Miles Bader]

Michael J Gruber <git@drmicha.warpmail.net> writes:
>> git add -A && git commit -m "Message"
>
> "commit -a" is much like "add -u", at least when used without file
> arguments ("pathspec").
>
> "commit -A" does not exist, so that "git add -A && git commit" is your
> only way.
>
> Why does it not exist? Because you should at least
> "git add -A && git status && behappy && git commit".

The exact same argument applies to "git commit -a" of course, but it's
still supported.  Why?  Because it's a nice convenience for many common
situations.  It isn't the least bit unsafe if one does git status _first_.

> 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.)

Nonsense.

The index is a great idea, and cool and useful in many situations; I use
it heavily, and wish other systems had something like it.  But there's
nothing "un-gitty" or "unfruitful" about directly commiting sometimes.

For the record, I usually use the index, but sometimes when the changes
are simple, I'll use shortcuts like "commit -a", because they're handy.
Typically I'll do "git status" _first_, check that everything's kosher,
and then do "git commit -a ...".  If "git commit -A" existed, I'd use
that in the same way.

-Miles

-- 
Mayonnaise, n. One of the sauces that serve the French in place of a state
religion.

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

[Michael J Gruber]

Miles Bader venit, vidit, dixit 25.02.2011 05:30:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>> git add -A && git commit -m "Message"
>>
>> "commit -a" is much like "add -u", at least when used without file
>> arguments ("pathspec").
>>
>> "commit -A" does not exist, so that "git add -A && git commit" is your
>> only way.
>>
>> Why does it not exist? Because you should at least
>> "git add -A && git status && behappy && git commit".
> 
> The exact same argument applies to "git commit -a" of course, but it's

No, because you are usually more aware of tracked files than of
untracked ones, especially in subdirs.

> still supported.  Why?  Because it's a nice convenience for many common
> situations.  It isn't the least bit unsafe if one does git status _first_.

That is why I recommended to use git status first. But "-A" is still
different, because (depending on your config) git status does not show
you files in untracked subdirs.

>> 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.)
> 
> Nonsense.
> 
> The index is a great idea, and cool and useful in many situations; I use
> it heavily, and wish other systems had something like it.  But there's
> nothing "un-gitty" or "unfruitful" about directly commiting sometimes.

And you can do that with "git add -A" followed by "git commit".

> For the record, I usually use the index, but sometimes when the changes

So if you use the index usually, it must be a fruitful habit. That
renders your "Nonsense" remark rather nonsensical.

> are simple, I'll use shortcuts like "commit -a", because they're handy.
> Typically I'll do "git status" _first_, check that everything's kosher,
> and then do "git commit -a ...".  If "git commit -A" existed, I'd use
> that in the same way.

It almost exists (add -A plus commit), and you carefully chose to ignore
my earlier posts about the implementation strategy leading to "commit
-A" (after I had looked at the details of the code - have you?), of
course, because otherwise the content of your post would be baseless;
the tone is anyway. No surprise here either.

Just for those wondering:

The "habit problem" with "commit -A" is that, potentially, it keeps
newcomers from learning vcs/git at all. It's a (too) wonderful way of
not having to worry even about the concept of "files under version
control" - this has nothing to do with using the index or not (that
would be the "-a" thingy). Even "svn commit" does not do what "git
commit -A" would.

No more posts from me on this subthread, it's just not worth it.
Michael

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

[Michael J Gruber]

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

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

[Jeff King]

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

-Peff

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

[Michael J Gruber]

Jeff King venit, vidit, dixit 25.02.2011 10:01:
> 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

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

[Jeff King]

On Fri, Feb 25, 2011 at 10:03:16AM +0100, Michael J Gruber wrote:

> > (which is why the default for commit with paths switched from "-i"
> > to "-o" long ago).
> 
> ...before my time (or under my radar).

Almost before my time, too. See 130fcca (git-commit: revamp the
git-commit semantics., 2006-02-05).

-Peff

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

[Michael J Gruber]

Marco venit, vidit, dixit 24.02.2011 19:45:
> 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.

Marco, please don't cull cc on this list. I haven't been aware of this
new subthread nor your answer in the other one (being culled).

Your questions have been answered in the subthread with Jeff already,
and we've laid out a way forward for the implementation.

Michael

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

[Junio C Hamano]

Marco <netuse@lavabit.com> writes:

> 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.

"It's not necessary to implement since we have add -A" is not what I said.
"I've shown the way long time ago, but that hasn't happened yet" was.

Luckily, it seems that it is changing now ;-).

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

[Miles Bader]

Michael J Gruber <git@drmicha.warpmail.net> writes:
> No more posts from me on this subthread, it's just not worth it.

Indeed, after sending my reply I read the rest of the messages on the
thread, and wished I hadn't replied at all.

Oh well; "read the whole thread before replying" is a lesson that needs
to be relearned occasionally I suppose...

-Miles

-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen