From: "Björn Steinbrink" <B.Steinbrink@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Björn Gustavsson" <bgustavsson@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 1/2] Documentation: 'git add -A' can remove files
Date: Mon, 7 Dec 2009 09:48:11 +0100 [thread overview]
Message-ID: <20091207084811.GA31622@atjola.homenet> (raw)
In-Reply-To: <7vbpib9r10.fsf@alter.siamese.dyndns.org>
On 2009.12.06 23:34:03 -0800, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > What I usually say on #git is something like:
> >
> > "git add <path>" looks at the working tree to find files
> > matching <path>. "git add -u <path>" looks at the index, and
> > "git add -A <path>" looks at both. Therefore "add" and "add -A"
> > can add new files to the index, and "add -u" and "add -A" can
> > remove files from it.
> >
> > And for convenience, -u and -A default to "." as the path argument.
>
> Hmm, an interesting way of teaching. How effective is it with the real new
> to mid-level users we see on the #git channel?
Hm, I wanted to check the channel logs for some reactions, but couldn't
find much. Apparently, I've not answered many question about add -u/-A
on #git since I switched to the above explanation (instead of saying
"git add -A is like git add . && git add -u" as I did in the past). For
the cases I found, the users didn't reply to the explanation. I can't
tell whether the explanation sucks, or whether the user was happy with
it or simply didn't care because he got the command he wanted.
I have two more data points for that kind of explanation in my Jabber
history, but those users aren't "new to mid-level" anymore.
And I recall only one really new user I told this to in face-to-face
"teaching", and that was right after explaining the index, so the
concept was present.
I guess the explanation might not be as easy to grok for someone that
doesn't have a good understanding of the index. For example, those that
still think that the index only stores changes (and is empty when no
"changes" have been staged) probably won't be able to make any sense out
of it.
Guess I'll have to apply a bunch of context when choosing which
explanation to use.
>
> > So maybe something like this?
> > ...
> > -A, --all
> > Like -u, but matches <filepattern> against files in the index in
> > addition to the files in working tree. This means that it can find
> > new files as well.
>
> Sounds easier to read to me but I think this description of "-A" seems
> backwards from your explanation. "Like -u" means "matches the index" and
> the difference is it in addition matches with the work tree, so it should
> probably be the other way around, i.e.
>
> Like -u, but matches <filepattern> against files in the work tree in
> addition to the index. This means that it can find new files as well.
Hm, I meant that to show that while -u uses the index _instead_ of the
working tree, -A uses the index _in_addition_to_ the working tree, i.e.
I meant to say how -A differs from -u WRT its effect compared to a plain
"git add".
IOW, I treat "git add" (working tree only) as the default behaviour. And
-u changes it to "index only", while -A changes it to "working tree +
index". Your version makes it look more like -A is a modification of -u.
OTOH, I also used to say "to update all tracked files, use add -u, and
to also add new files use add -A", which is better matched by your
wording. Though I'd go for this then:
Like -u, but also match <filepattern> against files in the working
tree. This means that it can find new files as well
Which just says what -A does on top of -u, without repeating what -u
does.
Björn
next prev parent reply other threads:[~2009-12-07 8:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-06 23:03 [PATCH 1/2] Documentation: 'git add -A' can remove files Björn Gustavsson
2009-12-06 23:31 ` Junio C Hamano
2009-12-07 0:57 ` Björn Steinbrink
2009-12-07 7:34 ` Junio C Hamano
2009-12-07 8:48 ` Björn Steinbrink [this message]
2009-12-07 0:05 ` 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=20091207084811.GA31622@atjola.homenet \
--to=b.steinbrink@gmx.de \
--cc=bgustavsson@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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