On 10/09/2013 08:55 PM, Jeff King wrote: > 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 > Oops my bad. I did not think this through. Maybe we could still have a config option, which either forbids it, or just shows a warning. I'll try to familiarize with the code and see what I can do. 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