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

2011/11/21 Junio C Hamano [off-list ref]:

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

quoted

If you want to keep this accident (which is a bug to me), you may want
to add the reason: callers to unpack_trees() are supposed to also
setup exclude rules in .git/info/exclude before calling
unpack_trees(), which they don't.

So .git/info/exclude is entirely dismissed.

Ohh, thanks for this and also for digging this through in your other
message.

I think it is the right thing to do to make sure .gitignore and
info/exclude behave the same way regardless of the original issue in this
topic.

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.

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.

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

Otherwise we would need to update excluded() in dir.c to return tristate
(ignored, precious or unspecified) instead of the current boolean (ignored
or unspecified), examine and decide for each caller what they want to do
to "precious" files.

IMO, as user, I think that erroring out telling you that 'cruft' will
be lost, is enough to avoid data loss.
However, in addition the tristate system (with a dedicated syntax in
.gitattributes and/or .gitignore files) would give more freedom,
without having to move 'untracked but precious' files between each
updated 'git checkout'.