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 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.