From: Michael J Gruber <git@drmicha.warpmail.net>
To: Miles Bader <miles@gnu.org>
Cc: Marco <netuse@lavabit.com>, git@vger.kernel.org
Subject: Re: Why doesn't git commit -a track new files
Date: Fri, 25 Feb 2011 09:43:03 +0100 [thread overview]
Message-ID: <4D676B97.3000204@drmicha.warpmail.net> (raw)
In-Reply-To: <buozkpk91nf.fsf@dhlpc061.dev.necel.com>
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
next prev parent reply other threads:[~2011-02-25 8:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-24 10:22 Why doesn't git commit -a track new files Marco
2011-02-24 14:06 ` Ævar Arnfjörð Bjarmason
2011-02-24 14:09 ` Pascal Obry
2011-02-24 14:20 ` Marco
2011-02-24 15:02 ` Michael J Gruber
2011-02-24 15:49 ` Jeff King
2011-02-24 15:54 ` Michael J Gruber
2011-02-24 16:00 ` Jeff King
2011-02-24 16:01 ` Michael J Gruber
2011-02-24 16:09 ` Jeff King
2011-02-25 8:51 ` Michael J Gruber
2011-02-25 9:01 ` Jeff King
2011-02-25 9:03 ` Michael J Gruber
2011-02-25 9:09 ` Jeff King
2011-02-24 16:04 ` Matthieu Moy
2011-02-24 16:04 ` Michael J Gruber
2011-02-24 16:47 ` Marco
2011-02-25 4:30 ` Miles Bader
2011-02-25 8:43 ` Michael J Gruber [this message]
2011-02-26 6:45 ` Miles Bader
2011-02-24 16:19 ` Marc Weber
2011-02-24 17:27 ` Junio C Hamano
2011-02-24 18:45 ` Marco
2011-02-25 10:15 ` Michael J Gruber
2011-02-25 17:00 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D676B97.3000204@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=miles@gnu.org \
--cc=netuse@lavabit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).