All of lore.kernel.org
 help / color / mirror / Atom feed
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.

      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.