# Bisect needing to be at repo top-level? 11 messages from 2013-09-17 to 2013-10-09. Participants: Burton, Ross, Junio C Hamano, Lukas Fleischer, Ben Aveling, Stefan Beller, Jeff King. Thread: https://gitlist.dev/t/34950 ## Burton, Ross, 2013-09-17 16:31 Subject: Bisect needing to be at repo top-level? Message-ID: URL: https://gitlist.dev/e/CAJTo0LZ%3DbNNUc8O%3DbDDOp2vudsc_wL%2B-nqsXW5r1rq3H7M0e7Q%40mail.gmail.com ``` 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 Hamano, 2013-09-17 17:27 Subject: Re: Bisect needing to be at repo top-level? Message-ID: URL: https://gitlist.dev/e/xmqqbo3rz7ca.fsf%40gitster.dls.corp.google.com In-Reply-To: ``` "Burton, Ross" 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? ``` ## Lukas Fleischer, 2013-09-17 17:58 Subject: Re: Bisect needing to be at repo top-level? Message-ID: <20130917175813.GA14173@blizzard> URL: https://gitlist.dev/e/20130917175813.GA14173%40blizzard In-Reply-To: ``` On Tue, Sep 17, 2013 at 10:27:49AM -0700, Junio C Hamano wrote: > "Burton, Ross" 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 ``` ## Burton, Ross, 2013-09-17 18:38 Subject: Re: Bisect needing to be at repo top-level? Message-ID: URL: https://gitlist.dev/e/CAJTo0LYp_FNfRYiLY3XivUxFN2JPCics%3DjbFsX%2BpVebEZ5XeSg%40mail.gmail.com In-Reply-To: ``` On 17 September 2013 18:27, Junio C Hamano wrote: > "Burton, Ross" 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 ``` ## Junio C Hamano, 2013-09-17 19:20 Subject: Re: Bisect needing to be at repo top-level? Message-ID: URL: https://gitlist.dev/e/xmqqioxzxnjh.fsf%40gitster.dls.corp.google.com In-Reply-To: <20130917175813.GA14173@blizzard> ``` Lukas Fleischer 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. ``` ## Ben Aveling, 2013-09-19 13:15 Subject: Re: Bisect needing to be at repo top-level? Message-ID: <523AF8EA.6080307@optusnet.com.au> URL: https://gitlist.dev/e/523AF8EA.6080307%40optusnet.com.au In-Reply-To: ``` On 18/9/13 05:20, Junio C Hamano wrote: > Lukas Fleischer 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 ``` ## Ben Aveling, 2013-09-19 22:46 Subject: Re: Bisect needing to be at repo top-level? Message-ID: <523B7EB9.9050809@optusnet.com.au> URL: https://gitlist.dev/e/523B7EB9.9050809%40optusnet.com.au In-Reply-To: <523AF8EA.6080307@optusnet.com.au> ``` On 19/9/13 23:15, Ben Aveling wrote: > On 18/9/13 05:20, Junio C Hamano wrote: >> Lukas Fleischer 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 Hamano, 2013-09-19 23:04 Subject: Re: Bisect needing to be at repo top-level? Message-ID: URL: https://gitlist.dev/e/xmqqpps4qups.fsf%40gitster.dls.corp.google.com In-Reply-To: <523B7EB9.9050809@optusnet.com.au> ``` Ben Aveling 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 Beller, 2013-10-09 18:27 Subject: Re: Bisect needing to be at repo top-level? Message-ID: <5255A02E.3050405@googlemail.com> URL: https://gitlist.dev/e/5255A02E.3050405%40googlemail.com In-Reply-To: ``` 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 fatal: checkout not possible, because of said reason (dangling pwd) $ cd ../.. # go to top level or somewhere else unaffected $ git checkout # 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 # 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 King, 2013-10-09 18:55 Subject: Re: Bisect needing to be at repo top-level? Message-ID: <20131009185459.GA2823@sigill.intra.peff.net> URL: https://gitlist.dev/e/20131009185459.GA2823%40sigill.intra.peff.net In-Reply-To: <5255A02E.3050405@googlemail.com> ``` 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 > fatal: checkout not possible, because of said reason (dangling pwd) > $ cd ../.. # go to top level or somewhere else unaffected > $ git checkout # 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 # 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 Beller, 2013-10-09 19:01 Subject: Re: Bisect needing to be at repo top-level? Message-ID: <5255A7FA.8090504@googlemail.com> URL: https://gitlist.dev/e/5255A7FA.8090504%40googlemail.com In-Reply-To: <20131009185459.GA2823@sigill.intra.peff.net> ``` 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 >> fatal: checkout not possible, because of said reason (dangling pwd) >> $ cd ../.. # go to top level or somewhere else unaffected >> $ git checkout # 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 # 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 ```