> > I'd like to propose adding a new standard gitattribute "precious". > > ;-). The version of CVS that I used to use, CVSNT, was a lot more careful about the user's files than Git is inclined to be. If CVSNT, while doing an Update, came across a non-tracked file that was in the way of something that it wanted to write, then the Update would be aborted showing a list of any files that were "in the way". The user could then rename/delete them or redo the Update with a "force" parameter to indicate that such items could be overwritten. Git has tended to take an approach of "if it's important it'll be tracked by Git - anything else can be trashed with impunity.". Over the years people have been caught out by this and lost work. It may well be that in a Linux development world anything other than tracked source files can be summarily deleted, but in a wider world, like Windows, or environments that are not software development, or that need special files lying around, this is not always an entirely reasonable approach. > Over the years, I've seen many times scenarios that would have been helped > if we had not just "tracked? ignored? unignored?" but also the fourth kind > [*]. The word "ignored" (or "excluded") has always meant "not tracked, not > to be tracked, and expendable" to Git, and "ignored but unexpendable" class > was missing. I even used the term "precious" myself in those discussions. At > the concept level, I support the effort 100%, but as always, the devil will be in > the details. > > Scenarios that people wished for "precious" traditionally have been > > * You are working on 'master'. You have in your .gitignore or > .git/info/exclude a line to ignore path A, and have random > scribbles in a throw-away file there. There is another branch > 'seen', where they added some tracked contents at path A/B. You > do "git checkout seen" and your file A that is an expendable file, > because it is listed as ignored in .git/info/exclude, is removed > to make room for creating A/B. So checkout aborts, saying "A is in the way". > * Similar situation, but this time, 'seen' branch added a tracked > contents at path A. Again, "git checkout seen" will discard the > expendable file A and replace it with tracked contents. So checkout aborts, saying "A is in the way". > * Instead of "git checkout", you decide to merge the branch 'seen' > to the checkout of 'master', where you have an ignored path A. > Because merging 'seen' would need to bring the tracked contents > of either A/B (in the first scenario above) or A (in the second > scenario), your "expendable" A will be removed to make room. So merge aborts, saying "A is in the way". It is entirely conventional to have merge conflicts that the user needs to resolve. This is just another kind of conflict. > In previous discussions, nobody was disturbed that "git clean" was unaware > of the "precious" class, but if we were to have the "precious" class in addition > to "ignored" aka "expendable", I would not oppose to teach "git clean" about > it, too. Indeed, if something is explicitly precious then nothing should summarily delete it. I know this goes against some stated design decisions of early Git, but in the CVSNT world *all* files were considered precious and would always cause an update to be aborted if there were any inclination to replace them. An option might be to state, in config, whether a project, or everything, should be managed on the basis of "all untracked files are precious" or "files may be explicitly marked precious", or, as now, "nothing is precious". Regards, Richard. PS. I think I've caught all places where my fingers typed "previous" when my brain meant "precious" - apologies if I've missed any.
