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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

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

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

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

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]