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