git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jiang Xin <worldhello.net@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH] Use clean.requireforce to protect untracked files.
Date: Fri, 03 Jun 2011 08:11:00 -0700	[thread overview]
Message-ID: <7vipsnar23.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <4DE8C1AE.4000007@gmail.com> (Jiang Xin's message of "Fri, 03 Jun 2011 19:12:46 +0800")

Jiang Xin <worldhello.net@gmail.com> writes:

> Untracked files may be significant for certain repositories, but if run the
> command "git clean -fdx" by accident, all untracked files will be lost.

Don't add -x without thinking, then. It is the way to tell the command "I
want to remove all the untracked files and I REALLY MEAN IT".  It is often
used to say "I do not trust Makefile and I want to remove what 'make
clean' would leave behind".

A slightly related tangent is that we only have three classes of paths:

 - tracked ones
 - untracked ones, where there are two subclasses
   - unignored ones (e.g. new source file you haven't added)
   - ignored ones (e.g. build artifacts like *.o files)

and because of that, the general design is to consider "ignored" files
expendable during various operations. Sometimes people deliberately "ignore"
files that they consider not expendable, which is (by today's definition)
a wrong thing to do, but I think in the longer term we should add a way to
mark them as "ignored but precious".

  http://thread.gmane.org/gmane.comp.version-control.git/172818/focus=172846

Nobody has designed how this fourth class should behave (and how the
behaviour of the "ignored" should change, if any) yet, but a rough outline
would probably be:

 - precious files are the ones that are ignored (by today's definition,
   i.e. .gitignore mechanism consideres they are ignored) but marked as
   "precious" in some other way [*1*]. They will

   - not appear in "Untracked files:" section in "git status" output;
   - not be added by "git add" without "-f", just like other ignored files;
   - not be overwritten or removed to make room while switching branches;
   - not be removed with "clean -f -x" [*2*].

 - ignored files will stay to be "expendable".

I suspect there may be some codepaths that incorrectly treat them as not
expendable, and protect their lossage. We would want to fix them after we
introduce the "precious" class.

[Footnotes]

*1* We could invent a way to sneak such entries in .gitignore, but I am
inclined to think it would be cleaner to define "precious" attribute and
let the attributes mechanism handle this.

*2* This is just off the top of my head without thinking things
through. It might turn out that it makes more sense ot remove them.

  reply	other threads:[~2011-06-03 15:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-03 11:12 [PATCH] Use clean.requireforce to protect untracked files Jiang Xin
2011-06-03 15:11 ` Junio C Hamano [this message]
2011-06-03 16:20   ` Jiang Xin

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=7vipsnar23.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=worldhello.net@gmail.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).