On Thu, Nov 24, 2011 at 12:16 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > >> On Mon, Nov 21, 2011 at 10:18 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> In the medium term, I think one reasonable way forward solving the "TODO >>> that used to be tracked but now untracked and ignored" issue is to >>> introduce "info/exclude-override" that comes between command line and >>> in-tree patterns. The info/exclude file is designed as the fallback >>> definition to be used when all other sources are too lax, and comes near >>> the precedence stack; the "TODO" situation however calls for an override >>> that is stronger than the in-tree patterns. >> >> "info/precious" might be a better name > > The above is only about the precedence order and is not about introducing > the new "precious" class at all. The way I see how info/exclude-override helps keep (ignored but) precious files is it un-ignores files that are ignored by info/exclude and .gitignore. But if we go that way, then git-add will also un-ignore precious files, allowing users to add them in-tree by mistake. >>> In the longer term, we should carefully determine if we need "precious" in >>> the first place. The last time this was brought up there were people who >>> argued they are OK with having to remove the ignored file by hand when >>> checking out another branch (i.e. we switch the semantics of "ignored" so >>> that they are "not tracked but all precious"). >>> >>> I think it matters in two cases. >>> >>> (1) If you change an untracked "cruft" file on branch A into a directory >>> with tracked files in it on another branch B. If you are on branch A, >>> have that "cruft" file (perhaps it is a build product after running >>> "make"), and try to checkout branch B, such an updated "git checkout" >>> will start erroring out telling you that "cruft" will be lost. >>> >>> (2) If you have a directory on branch A, underneath of which there are >>> untracked "cruft" files (e.g. think "build/" directory that is full >>> of "*.o" files and ".gitignore" to mark object files as ignored but >>> is otherwise empty), and another branch B that has the same path as a >>> file. If you are on branch A, have "cruft" files in that directory, >>> and try to checkout branch B, such an updated "git checkout" will >>> start erroring out telling you that "cruft" will be lost. >> >> I think we should do this regardless precious being added or not. > > Because (see below)? Because it may potentially lose user's changes. Assume file "A" is tracked and also ignored. Users may make some changes in A, then move HEAD away without touching worktree, now HEAD does not see "A" as tracked any more. If we switch to a branch that has A tracked, git may override A and wipe our user changes in that file. In short, if a file is tracked (either in source or target in 2-way merge) then we ignore excluded() result on that file. >>> If people are OK with such a behaviour, we can do without "precious". >> >> What about git-clean to remove ignored but not precious files? > (git clean without -x snipped because I was talking about -x) > > "clean -x" is more subtle. It has been a way to say "Remove cruft the > usual way, and in addition, remove the expendable build products, just > like 'make clean' _should_ do, but I do not trust my Makefile". If we > introduced "precious", it would be very clear what it should do---even > with "-x" precious files should be kept. But if we don't and just try to > get away by changing the semantics of "ignored", they will still need to > be removed, so we won't really get the "precious". > > The conclusion from this is that it is a mistake to change the semantics > of "ignored" from the current "untracked and expendable if needed" if the > purpose of that change is to avoid introducing the new "precious" class. > > I don't care too much about it, as I do not use "git clean -x" myself ;-) > but that wouldn't stop others from think about the issue and try to come > up with a good solid design. I don't use "git clean -x" myself either. This is just some input to the discussion and true users are supposed to speak up. The point I want to make is, if users really want the ability remove non-precious ignored files, then we may need to add the new "precious" class that (and you seem to reach the same conclusion). -- Duy -- 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