Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude

Nguyen Thai Ngoc Duy [off-list ref] writes:

On Mon, Nov 21, 2011 at 10:18 PM, Junio C Hamano [off-list ref] wrote:

quoted

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.

quoted

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)?

quoted

If people are OK with such a behaviour, we can do without "precious".

What about git-clean to remove ignored but not precious files?

"clean" without -x is a way to remove untracked and not ignored files,
i.e. remove "test.c", "trash-patch", "notes" that are not part of the
sources but were crufts you hand generated during your development process
that you do not need, without removing build products such as "main.o". If
we switch the semantics of "ignored" from "untracked and is expendable for
the purpose of checking out another conflicting branch" to "untracked but
is not expendable", it is clear that it should not remove them.

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

Or do excluded() twice, the first time to check for precious files,
the second for all ignored rules. Callers are changed anyway, but this
way git-add for example will be untouched because it does not care
about precious stuff. Only unpack-trees and maybe git-clean are
changed.

I don't think we want to go there, as it will encourage different
codepaths doing different things without a good reason. Having to add
ignore source manually in different codepaths was the real cause of the
inconsistency bug around info/exclude vs .gitignore we discussed earlier.