From: "Wesley J. Landaker" <wjl@icecavern.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/2] Documentation: git-clean: description updates
Date: Sat, 25 Apr 2009 19:33:55 -0600 [thread overview]
Message-ID: <200904251933.56710.wjl@icecavern.net> (raw)
In-Reply-To: <7vhc0cxok0.fsf@gitster.siamese.dyndns.org>
On Saturday 25 April 2009 18:10:23 Junio C Hamano wrote:
> Thanks, will queue for 1.6.3, as I think both are clearly improvements.
>
> One could argue that the second one could be further improved, but I do
> not see anything controversial in it.
Okay, great! I'm all for incremental improvements, so please do hack my patch
up if it helps!
> This allows cleaning the working tree by removing files that are not
> under version control.
>
> Normally, only files unknown to git are removed, but if the '-x'
> option is specified, ignored files are also removed. This can, for
> example, be useful to remove all build products.
>
> The only iffy point I can see is that "unknown" is a bit fuzzy phrase in
> this context. I know what you mean, but you are not writing for people
> who know what "git clean" does ;-)
>
> In the above, "unknown" refers to a set of files that is a strict subset
> of "untracked" files, excluding the "ignored" set. But that is not
> defined anywhere in the glossary.
>
> Sometimes we colloquially say "files _known_ to git" to refer to "tracked"
> files (paths that appear in the index). But your "files _unknown_ to git"
> is different from the complement of it.
>
> The saddest part is that "untracked files" is not defined in the glossary
> either.
Well, I wasn't sure how to canonically refer to "git that git does not track
but also does not have ignore rules for" and "files that git ignores", so I
tried to mostly just use the same terminology I saw kicking around in other
documentation. I think "unknown files" and "ignored files" are fairly clear and
seem like the terms I usually hear people using. If we add them to the
glossary then we could use them in a standard way in the documentation.
> Normally, the command removes files that are not in the index, but
> ignored (see linkgit:gitignore[5]) files are kept. With the '-x'
> option, the command removes the ignored files as well.
Are you already queuing this or any of these other things? If not, I would be
happy to work on another patchset that attacks both this and the glossary
issue.
prev parent reply other threads:[~2009-04-26 1:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-25 15:13 [PATCH 0/2] Documentation: git-clean: description updates Wesley J. Landaker
2009-04-25 15:13 ` [PATCH 1/2] Documentation: git-clean: fix minor grammatical errors Wesley J. Landaker
2009-04-25 15:13 ` [PATCH 2/2] Documentation: git-clean: make description more readable Wesley J. Landaker
2009-04-25 18:36 ` Stephen Boyd
2009-04-26 1:23 ` Wesley J. Landaker
2009-04-26 8:04 ` Stephen Boyd
2009-04-26 0:10 ` [PATCH 0/2] Documentation: git-clean: description updates Junio C Hamano
2009-04-26 1:33 ` Wesley J. Landaker [this message]
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=200904251933.56710.wjl@icecavern.net \
--to=wjl@icecavern.net \
--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;
as well as URLs for NNTP newsgroup(s).