Re: [PATCH] Use clean.requireforce to protect untracked files.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jiang Xin <worldhello.net@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]