{"thread":{"id":"34950","subject":"Bisect needing to be at repo top-level?","startedAt":"2013-09-17T16:31:57Z","lastAt":"2013-10-09T19:01:14Z","messageCount":11,"participants":["Burton, Ross","Junio C Hamano","Lukas Fleischer","Ben Aveling","Stefan Beller","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"227757","messageId":"CAJTo0LZ=bNNUc8O=bDDOp2vudsc_wL+-nqsXW5r1rq3H7M0e7Q@mail.gmail.com","threadId":"34950","inReplyTo":null,"subject":"Bisect needing to be at repo top-level?","fromName":"Burton, Ross","fromEmail":"ross.burton@intel.com","sentAt":"2013-09-17T16:31:57Z","receivedAt":"2013-09-17T16:31:57Z","isPatch":false,"sender":{"key":"ross.burton@intel.com","avatar":null},"body":"Hi,\n\nWhy does git-bisect need to be ran from the top level of the working\ntree? It sources git-sh-setup.sh which sets GIT_DIR, which\ngit-bisect.sh then appears to consistently use. Is there a reason for\nneeding to be at the top-level, or is this an old and redundant\nmessage?\n\nCheers,\nRoss\n"},{"id":"227765","messageId":"xmqqbo3rz7ca.fsf@gitster.dls.corp.google.com","threadId":"34950","inReplyTo":"CAJTo0LZ=bNNUc8O=bDDOp2vudsc_wL+-nqsXW5r1rq3H7M0e7Q@mail.gmail.com","subject":"Re: Bisect needing to be at repo top-level?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-17T17:27:49Z","receivedAt":"2013-09-17T17:27:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Burton, Ross\" writes:\n\n> Why does git-bisect need to be ran from the top level of the working\n> tree? It sources git-sh-setup.sh which sets GIT_DIR, which\n> git-bisect.sh then appears to consistently use. Is there a reason for\n> needing to be at the top-level, or is this an old and redundant\n> message?\n\nA wild guess.\n\nImagine if you start from a subdirectory foo/ but the directory did\nnot exist in the older part of the history of the project. When\nbisect needs to check out a revision that was older than the first\nrevision that introduced that subdirectory, what should happen?\nWorse yet, if \"foo\" was a file in the older part of the history,\nwhat should happen?\n"},{"id":"227767","messageId":"20130917175813.GA14173@blizzard","threadId":"34950","inReplyTo":"xmqqbo3rz7ca.fsf@gitster.dls.corp.google.com","subject":"Re: Bisect needing to be at repo top-level?","fromName":"Lukas Fleischer","fromEmail":"git@cryptocrack.de","sentAt":"2013-09-17T17:58:13Z","receivedAt":"2013-09-17T17:58:13Z","isPatch":false,"sender":{"key":"git@cryptocrack.de","avatar":null},"body":"On Tue, Sep 17, 2013 at 10:27:49AM -0700, Junio C Hamano wrote:\n> \"Burton, Ross\" writes:\n> \n> > Why does git-bisect need to be ran from the top level of the working\n> > tree? It sources git-sh-setup.sh which sets GIT_DIR, which\n> > git-bisect.sh then appears to consistently use. Is there a reason for\n> > needing to be at the top-level, or is this an old and redundant\n> > message?\n> \n> A wild guess.\n> \n> Imagine if you start from a subdirectory foo/ but the directory did\n> not exist in the older part of the history of the project. When\n> bisect needs to check out a revision that was older than the first\n> revision that introduced that subdirectory, what should happen?\n> Worse yet, if \"foo\" was a file in the older part of the history,\n> what should happen?\n\nIf that is the real explanation, why do we allow running git-checkout(1)\nfrom a subdirectory?\n\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"227772","messageId":"CAJTo0LYp_FNfRYiLY3XivUxFN2JPCics=jbFsX+pVebEZ5XeSg@mail.gmail.com","threadId":"34950","inReplyTo":"xmqqbo3rz7ca.fsf@gitster.dls.corp.google.com","subject":"Re: Bisect needing to be at repo top-level?","fromName":"Burton, Ross","fromEmail":"ross.burton@intel.com","sentAt":"2013-09-17T18:38:46Z","receivedAt":"2013-09-17T18:38:46Z","isPatch":false,"sender":{"key":"ross.burton@intel.com","avatar":null},"body":"On 17 September 2013 18:27, Junio C Hamano wrote:\n> \"Burton, Ross\" writes:\n>\n>> Why does git-bisect need to be ran from the top level of the working\n>> tree? It sources git-sh-setup.sh which sets GIT_DIR, which\n>> git-bisect.sh then appears to consistently use. Is there a reason for\n>> needing to be at the top-level, or is this an old and redundant\n>> message?\n>\n> A wild guess.\n>\n> Imagine if you start from a subdirectory foo/ but the directory did\n> not exist in the older part of the history of the project. When\n> bisect needs to check out a revision that was older than the first\n> revision that introduced that subdirectory, what should happen?\n> Worse yet, if \"foo\" was a file in the older part of the history,\n> what should happen?\n\n\"git checkout\" doesn't mandate that you're at the top-level, so that's\nnot a very strong argument.\n\nRoss\n"},{"id":"227776","messageId":"xmqqioxzxnjh.fsf@gitster.dls.corp.google.com","threadId":"34950","inReplyTo":"20130917175813.GA14173@blizzard","subject":"Re: Bisect needing to be at repo top-level?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-17T19:20:50Z","receivedAt":"2013-09-17T19:20:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lukas Fleischer writes:\n\n>> Imagine if you start from a subdirectory foo/ but the directory did\n>> not exist in the older part of the history of the project. When\n>> bisect needs to check out a revision that was older than the first\n>> revision that introduced that subdirectory, what should happen?\n>> Worse yet, if \"foo\" was a file in the older part of the history,\n>> what should happen?\n>\n> If that is the real explanation,\n\nNo. As the line you snipped from your quote says, it is just a\nguess without running \"git log -- git-bisect.sh git-bisect-script\".\n\nAlso it points at things one needs to watch out for and think about\nwhen attempting to update \"git bisect\" to make it possible to run it\nanywhere in the working tree.\n\n> why do we allow running git-checkout(1)\n> from a subdirectory?\n\nOversight?\n\nAt least on Linux, if you checkout a revision with \"foo/\" directory,\nchdir to it and then checkout a revision with \"foo\" file to nuke\nyour current place, I know \"git checkout\" will happily do so and you\nwill still be in a directory that is connected nowhere. Your \"..\"\nis probably pointing at the top-level, but there is no reverse, so\n\"cd ../foo\" may or may not work from that state, and it would lead\nto an interesting confusion.\n\nWe may want to check the condition and forbid such a checkout.\n"},{"id":"227884","messageId":"523AF8EA.6080307@optusnet.com.au","threadId":"34950","inReplyTo":"xmqqioxzxnjh.fsf@gitster.dls.corp.google.com","subject":"Re: Bisect needing to be at repo top-level?","fromName":"Ben Aveling","fromEmail":"bena.001@optusnet.com.au","sentAt":"2013-09-19T13:15:22Z","receivedAt":"2013-09-19T13:15:22Z","isPatch":false,"sender":{"key":"bena.001@optusnet.com.au","avatar":null},"body":"On 18/9/13 05:20, Junio C Hamano wrote:\n> Lukas Fleischer writes:\n>\n>> why do we allow running git-checkout(1)\n>> from a subdirectory?\n> We may want to check the condition and forbid such a checkout.\n\nIt would probably make sense.\n\nIt might also make sense to relax the check in git bisect somewhat. \nCurrently, even \"git bisect help\" insists that \"You need to run this \ncommand from the toplevel of the working tree.\"\n\nRegards, Ben\n"},{"id":"227906","messageId":"523B7EB9.9050809@optusnet.com.au","threadId":"34950","inReplyTo":"523AF8EA.6080307@optusnet.com.au","subject":"Re: Bisect needing to be at repo top-level?","fromName":"Ben Aveling","fromEmail":"bena.001@optusnet.com.au","sentAt":"2013-09-19T22:46:17Z","receivedAt":"2013-09-19T22:46:17Z","isPatch":false,"sender":{"key":"bena.001@optusnet.com.au","avatar":null},"body":"On 19/9/13 23:15, Ben Aveling wrote:\n> On 18/9/13 05:20, Junio C Hamano wrote:\n>> Lukas Fleischer writes:\n>>> why do we allow running git-checkout(1)\n>>> from a subdirectory?\n>> We may want to check the condition and forbid such a checkout.\n> It would probably make sense.\n> It might also make sense to relax the check in git bisect somewhat. \n> Currently, even \"git bisect help\" insists that \"You need to run this \n> command from the toplevel of the working tree.\"\n\nProbably also worth pointing out that whether or not the current shell \nis at toplevel, there can be other processes active in subdirectories.\n\n Regards, Ben\n"},{"id":"227908","messageId":"xmqqpps4qups.fsf@gitster.dls.corp.google.com","threadId":"34950","inReplyTo":"523B7EB9.9050809@optusnet.com.au","subject":"Re: Bisect needing to be at repo top-level?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-19T23:04:31Z","receivedAt":"2013-09-19T23:04:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ben Aveling writes:\n\n> Probably also worth pointing out that whether or not the current shell\n> is at toplevel, there can be other processes active in subdirectories.\n\nThat is not something we have control over anyway.\n"},{"id":"228664","messageId":"5255A02E.3050405@googlemail.com","threadId":"34950","inReplyTo":"xmqqioxzxnjh.fsf@gitster.dls.corp.google.com","subject":"Re: Bisect needing to be at repo top-level?","fromName":"Stefan Beller","fromEmail":"stefanbeller@googlemail.com","sentAt":"2013-10-09T18:27:58Z","receivedAt":"2013-10-09T18:27:58Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"Reigniting the discussion from three weeks ago:\nI found it at http://git-blame.blogspot.de/search?q=leftover\n\nOn 09/17/2013 09:20 PM, Junio C Hamano wrote:\n> \n> At least on Linux, if you checkout a revision with \"foo/\" directory,\n> chdir to it and then checkout a revision with \"foo\" file to nuke\n> your current place, I know \"git checkout\" will happily do so and you\n> will still be in a directory that is connected nowhere. Your \"..\"\n> is probably pointing at the top-level, but there is no reverse, so\n> \"cd ../foo\" may or may not work from that state, and it would lead\n> to an interesting confusion.\n> \n> We may want to check the condition and forbid such a checkout.\n\nI think forbidding such a checkout is a bit hard:\n\t$ git checkout \n\tfatal: checkout not possible, because of said reason (dangling pwd)\n\t$ cd ../.. # go to top level or somewhere else unaffected\n\t$ git checkout # this will work\n\nWouldn't it be better to navigate to the 'nearest' possible working dir on checkout?\nSuch a workflow would emerge:\n\t$ git checkout # this includes the \"cd ..\" of the previous step, it just went the dir structure up, until a valid dir was found.\n\twarning: the current working directory is not part of the tree, navigating to $(PWD)\n\nPersonally I feel this is more what you'd actually want.\nThis discussion will become interesting once we have a commit (mostly?) renaming a folder:\n\tdir1/* => dir2/*\n\t\nIf you're checking out accross such a change, we'd end up in the top level\ndirectory, which is safe, but maybe not fully optimal. But still better than forbidding\nit in the first run.\n\nStefan\n"},{"id":"228666","messageId":"20131009185459.GA2823@sigill.intra.peff.net","threadId":"34950","inReplyTo":"5255A02E.3050405@googlemail.com","subject":"Re: Bisect needing to be at repo top-level?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-10-09T18:55:00Z","receivedAt":"2013-10-09T18:55:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 09, 2013 at 08:27:58PM +0200, Stefan Beller wrote:\n\n> > At least on Linux, if you checkout a revision with \"foo/\" directory,\n> > chdir to it and then checkout a revision with \"foo\" file to nuke\n> > your current place, I know \"git checkout\" will happily do so and you\n> > will still be in a directory that is connected nowhere. Your \"..\"\n> > is probably pointing at the top-level, but there is no reverse, so\n> > \"cd ../foo\" may or may not work from that state, and it would lead\n> > to an interesting confusion.\n> > \n> > We may want to check the condition and forbid such a checkout.\n> \n> I think forbidding such a checkout is a bit hard:\n> \t$ git checkout \n> \tfatal: checkout not possible, because of said reason (dangling pwd)\n> \t$ cd ../.. # go to top level or somewhere else unaffected\n> \t$ git checkout # this will work\n> \n> Wouldn't it be better to navigate to the 'nearest' possible working dir on checkout?\n> Such a workflow would emerge:\n> \t$ git checkout # this includes the \"cd ..\" of the previous step, it just went the dir structure up, until a valid dir was found.\n> \twarning: the current working directory is not part of the tree, navigating to $(PWD)\n\nThe problem is that the program calling \"git checkout\" (e.g., the shell)\nis in the directory that is going away, and git cannot impact the\nworking directory of its parent. So there is no way to \"fix\" it here.\nOur only options are to proceed and hope the user can figure it out, or\nto warn/forbid.\n\n-Peff\n"},{"id":"228667","messageId":"5255A7FA.8090504@googlemail.com","threadId":"34950","inReplyTo":"20131009185459.GA2823@sigill.intra.peff.net","subject":"Re: Bisect needing to be at repo top-level?","fromName":"Stefan Beller","fromEmail":"stefanbeller@googlemail.com","sentAt":"2013-10-09T19:01:14Z","receivedAt":"2013-10-09T19:01:14Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On 10/09/2013 08:55 PM, Jeff King wrote:\n> On Wed, Oct 09, 2013 at 08:27:58PM +0200, Stefan Beller wrote:\n> \n>>> At least on Linux, if you checkout a revision with \"foo/\" directory,\n>>> chdir to it and then checkout a revision with \"foo\" file to nuke\n>>> your current place, I know \"git checkout\" will happily do so and you\n>>> will still be in a directory that is connected nowhere. Your \"..\"\n>>> is probably pointing at the top-level, but there is no reverse, so\n>>> \"cd ../foo\" may or may not work from that state, and it would lead\n>>> to an interesting confusion.\n>>>\n>>> We may want to check the condition and forbid such a checkout.\n>>\n>> I think forbidding such a checkout is a bit hard:\n>> \t$ git checkout \n>> \tfatal: checkout not possible, because of said reason (dangling pwd)\n>> \t$ cd ../.. # go to top level or somewhere else unaffected\n>> \t$ git checkout # this will work\n>>\n>> Wouldn't it be better to navigate to the 'nearest' possible working dir on checkout?\n>> Such a workflow would emerge:\n>> \t$ git checkout # this includes the \"cd ..\" of the previous step, it just went the dir structure up, until a valid dir was found.\n>> \twarning: the current working directory is not part of the tree, navigating to $(PWD)\n> \n> The problem is that the program calling \"git checkout\" (e.g., the shell)\n> is in the directory that is going away, and git cannot impact the\n> working directory of its parent. So there is no way to \"fix\" it here.\n> Our only options are to proceed and hope the user can figure it out, or\n> to warn/forbid.\n> \n> -Peff\n> \n\nOops my bad. I did not think this through.\n\nMaybe we could still have a config option,\nwhich either forbids it, or just shows a warning.\nI'll try to familiarize with the code and see what I can do.\n\nStefan\n"}]}