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

[Bertrand BENOIT <projettwk@users.sourceforge.net>]

2011/11/21 Junio C Hamano <gitster@pobox.com>:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> 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'.