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.


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

Reply via email to