On Fri, Mar 17, 2017 at 5:23 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nevada Sanchez <sanchez.nevada@xxxxxxxxx> writes: > >> Here's an easy to reproduce bug. It's the only example I know of where >> git legitimately loses data in a way that is unrecoverable, >> unexpected, and without warning. > > This is an example of a user explicitly telling git to discard data > and git performing as it is told. > > There is no "untracked but precious" vs "untracked and expendable" > difference in the current system. An untracked file that matches > patterns listed in .gitignore is treated as the latter. > > When you have an untracked file that .gitignore knows about in the > working tree while you are on "feature", if switching to another > branch requires to remove that file, the content there is deemed > expendable, because the user said so by listing it in .gitignore. > > We've discussed the lack of "untracked but precious" class a few > times on the list in the past, but I do not recall the topic came up > in the recent past. It perhaps is because nobody found that class > useful enough so far. I must admit that I missed that attribute of .gitignore (i.e. untracked and **expendable**). I have grown accustomed to Git being rather conservative and erring on the side of not losing data unless the user is doing something deliberate (for example, 'git clean' won't work unless you force it, checkouts fail if they do anything that might lose data... unless it is in .gitignore, as I just learned). When I saw this behavior, I assumed that it was a bug. This isn't necessarily a situation I need to have fixed--it is not part of my workflow and since that fateful commit, all feature branches checked out after the change to .gitignore will not have any problems as I switch branches. It was an unfortunate surprise to one of my co-workers, not long after I reassured him that git was conservative and will almost never accidentally lose data (even if it means going to 'git reflog'). In keeping with this spirit, I would tend to lean towards having "untracked but precious" being the default behavior (more conservative), and if a user wants "untracked but expendable" behavior, then that case requires special effort from the user (like learning about and using a new type of ignore file). My guess is that if the user is both ignoring and committing something to their repository, it is probably a mistake, and as that user, I would rather discover that mistake early with loud warning messages (and/or a suggestion to use an alternate ignore strategy, or config flag), than learn about it by losing data. In summary, I do not need this fixed for my workflow, but want to bring it to light in case other users are being similarly surprised. I struggle to guess how far reaching of an impact it would have on existing users to change the default behavior, but it would probably be less than that of the push default behavior change that happened not too long ago. A quick and easy immediate step is to make note of this behavior in the very first sentence of gitignore(5): > A gitignore file specifies intentionally untracked files that Git should ignore *and that Git is allowed to overwrite without warning*. More details about untracked but expendable can be placed in the NOTES section, but the last part of that sentence would be quite helpful. Thank you, -Nevada