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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 23, 2011, 17:16 UTC
Message-ID: <7vy5v6bvy4.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8A7HVe8kLR5j9Ej0tJhpkxigCXRqpg9DvE9qJsfengi1Q@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

Show 10 quoted lines

> On Mon, Nov 21, 2011 at 10:18 PM, Junio C Hamano <gitster@pobox.com> 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.

Show 23 quoted lines

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

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

Show 5 quoted lines

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