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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Miles Bader venit, vidit, dixit 25.02.2011 05:30:
> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]