Bisect needing to be at repo top-level?

Bisect needing to be at repo top-level?

[Burton, Ross]

Hi,

Why does git-bisect need to be ran from the top level of the working
tree?  It sources git-sh-setup.sh which sets GIT_DIR, which
git-bisect.sh then appears to consistently use.  Is there a reason for
needing to be at the top-level, or is this an old and redundant
message?

Cheers,
Ross

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

[Junio C Hamano]

"Burton, Ross" <ross.burton@intel.com> writes:

> Why does git-bisect need to be ran from the top level of the working
> tree?  It sources git-sh-setup.sh which sets GIT_DIR, which
> git-bisect.sh then appears to consistently use.  Is there a reason for
> needing to be at the top-level, or is this an old and redundant
> message?

A wild guess.

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?

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

[Lukas Fleischer]

On Tue, Sep 17, 2013 at 10:27:49AM -0700, Junio C Hamano wrote:
> "Burton, Ross" <ross.burton@intel.com> writes:
> 
> > Why does git-bisect need to be ran from the top level of the working
> > tree?  It sources git-sh-setup.sh which sets GIT_DIR, which
> > git-bisect.sh then appears to consistently use.  Is there a reason for
> > needing to be at the top-level, or is this an old and redundant
> > message?
> 
> A wild guess.
> 
> 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, why do we allow running git-checkout(1)
from a subdirectory?

> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Burton, Ross]

On 17 September 2013 18:27, Junio C Hamano <gitster@pobox.com> wrote:
> "Burton, Ross" <ross.burton@intel.com> writes:
>
>> Why does git-bisect need to be ran from the top level of the working
>> tree?  It sources git-sh-setup.sh which sets GIT_DIR, which
>> git-bisect.sh then appears to consistently use.  Is there a reason for
>> needing to be at the top-level, or is this an old and redundant
>> message?
>
> A wild guess.
>
> 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?

"git checkout" doesn't mandate that you're at the top-level, so that's
not a very strong argument.

Ross

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

[Junio C Hamano]

Lukas Fleischer <git@cryptocrack.de> writes:

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

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

[Ben Aveling]

On 18/9/13 05:20, Junio C Hamano wrote:
> Lukas Fleischer <git@cryptocrack.de> writes:
>
>> why do we allow running git-checkout(1)
>> from a subdirectory?
> We may want to check the condition and forbid such a checkout.

It would probably make sense.

It might also make sense to relax the check in git bisect somewhat. 
Currently, even "git bisect help" insists that "You need to run this 
command from the toplevel of the working tree."

Regards, Ben

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

[Ben Aveling]

On 19/9/13 23:15, Ben Aveling wrote:
> On 18/9/13 05:20, Junio C Hamano wrote:
>> Lukas Fleischer <git@cryptocrack.de> writes:
>>> why do we allow running git-checkout(1)
>>> from a subdirectory?
>> We may want to check the condition and forbid such a checkout.
> It would probably make sense.
> It might also make sense to relax the check in git bisect somewhat. 
> Currently, even "git bisect help" insists that "You need to run this 
> command from the toplevel of the working tree."

Probably also worth pointing out that whether or not the current shell 
is at toplevel, there can be other processes active in subdirectories.

     Regards, Ben

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

[Junio C Hamano]

Ben Aveling <bena.001@optusnet.com.au> writes:

> Probably also worth pointing out that whether or not the current shell
> is at toplevel, there can be other processes active in subdirectories.

That is not something we have control over anyway.

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

[Stefan Beller]

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

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

[Jeff King]

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

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

[Stefan Beller]

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