Re: Bisect needing to be at repo top-level?

From: Stefan Beller <stefanbeller@googlemail.com>
Date: Oct 9, 2013, 18:27 UTC
Message-ID: <5255A02E.3050405@googlemail.com>
In-Reply-To: <xmqqioxzxnjh.fsf@gitster.dls.corp.google.com>

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:

Show 10 quoted lines

> 
> 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