threads / discuss / 34950
Subject: Bisect needing to be at repo top-level?
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
Junio C HamanoRe: Bisect needing to be at repo top-level?
"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?
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
Junio C HamanoRe: Bisect needing to be at repo top-level?
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?
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?
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
Junio C HamanoRe: Bisect needing to be at repo top-level?
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.
Stefan BellerRe: Bisect needing to be at repo top-level?
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
Jeff KingRe: Bisect needing to be at repo top-level?
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
Stefan BellerRe: Bisect needing to be at repo top-level?
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
Re: Bisect needing to be at repo top-level?
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