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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.