Reigniting the discussion from three weeks ago: I found it at http://git-blame.blogspot.de/search?q=leftover On 09/17/2013 09:20 PM, Junio C Hamano wrote: > > At least on Linux, if you checkout a revision with "foo/" directory, > chdir to it and then checkout a revision with "foo" file to nuke > your current place, I know "git checkout" will happily do so and you > will still be in a directory that is connected nowhere. Your ".." > is probably pointing at the top-level, but there is no reverse, so > "cd ../foo" may or may not work from that state, and it would lead > to an interesting confusion. > > We may want to check the condition and forbid such a checkout. I think forbidding such a checkout is a bit hard: $ git checkout <branch> fatal: checkout not possible, because of said reason (dangling pwd) $ cd ../.. # go to top level or somewhere else unaffected $ git checkout <branch> # this will work Wouldn't it be better to navigate to the 'nearest' possible working dir on checkout? Such a workflow would emerge: $ git checkout <branch> # this includes the "cd .." of the previous step, it just went the dir structure up, until a valid dir was found. warning: the current working directory is not part of the tree, navigating to $(PWD) Personally I feel this is more what you'd actually want. This discussion will become interesting once we have a commit (mostly?) renaming a folder: dir1/* => dir2/* If you're checking out accross such a change, we'd end up in the top level directory, which is safe, but maybe not fully optimal. But still better than forbidding it in the first run. Stefan -- 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