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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 17, 2013, 19:20 UTC
Message-ID: <xmqqioxzxnjh.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20130917175813.GA14173@blizzard>

Lukas Fleischer <git@cryptocrack.de> writes:

Show 8 quoted lines

>> Imagine if you start from a subdirectory foo/ but the directory did
>> not exist in the older part of the history of the project.  When
>> bisect needs to check out a revision that was older than the first
>> revision that introduced that subdirectory, what should happen?
>> Worse yet, if "foo" was a file in the older part of the history,
>> what should happen?
>
> If that is the real explanation,

No. As the line you snipped from your quote says, it is just a guess without running "git log -- git-bisect.sh git-bisect-script".

Also it points at things one needs to watch out for and think about when attempting to update "git bisect" to make it possible to run it anywhere in the working tree.

> why do we allow running git-checkout(1)
> from a subdirectory?

Oversight?

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.