On Wed, Oct 09, 2013 at 08:27:58PM +0200, Stefan Beller 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)
The problem is that the program calling "git checkout" (e.g., the shell) is in the directory that is going away, and git cannot impact the working directory of its parent. So there is no way to "fix" it here. Our only options are to proceed and hope the user can figure it out, or to warn/forbid. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
