{"thread":{"id":"54474","subject":"[PATCH] bisect: allow `git bisect` to run from subdirectory","startedAt":"2020-10-21T09:09:09Z","lastAt":"2020-10-23T15:48:42Z","messageCount":14,"participants":["Sangeeta via GitGitGadget","Phillip Wood","Taylor Blau","Junio C Hamano","Johannes Schindelin","Sangeeta NB"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"408041","messageId":"pull.765.git.1603271344522.gitgitgadget@gmail.com","threadId":"54474","inReplyTo":null,"subject":"[PATCH] bisect: allow `git bisect` to run from subdirectory","fromName":"Sangeeta via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2020-10-21T09:09:04Z","receivedAt":"2020-10-21T09:09:09Z","isPatch":true,"sender":{"key":"sangunb09@gmail.com","avatar":"https://avatars.githubusercontent.com/u/64827599?v=4"},"body":"From: Sangeeta Jain <sangunb09@gmail.com>\n\nAs `git rebase` was never prevented to run from subdirectory we shouldn't\nprevent `git bisect` to run from subdirectories. This commit removes the\nrestriction on git bisect to run only from top level directory thereby\nallowing it to run from any subdirectory.\n\nSigned-off-by: Sangeeta Jain <sangunb09@gmail.com>\n---\n    [Outreachy] bisect: allow git bisect to run from subdirectory\n    \n    As git rebase was never prevented to run from subdirectory we shouldn't\n    prevent git bisect to run from subdirectories. This commit removes the\n    restriction on git bisect to run only from top level directory thereby\n    allowing it to run from any subdirectory.\n    \n    Signed-off-by: Sangeeta Jain sangunb09@gmail.com [sangunb09@gmail.com]\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-765%2Fsangu09%2Fbisect_fix-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-765/sangu09/bisect_fix-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/765\n\n git-bisect.sh               | 1 +\n t/t6030-bisect-porcelain.sh | 7 +++++++\n 2 files changed, 8 insertions(+)\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex ea7e684ebb..9cd0fa0483 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -32,6 +32,7 @@ git bisect run <cmd>...\n Please use \"git help bisect\" to get the full man page.'\n \n OPTIONS_SPEC=\n+SUBDIRECTORY_OK=Yes\n . git-sh-setup\n \n _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'\ndiff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh\nindex aa226381be..6b68cc01d0 100755\n--- a/t/t6030-bisect-porcelain.sh\n+++ b/t/t6030-bisect-porcelain.sh\n@@ -49,6 +49,13 @@ test_expect_success 'bisect starts with only one bad' '\n \tgit bisect next\n '\n \n+test_expect_success 'bisect runs in a subdirectory' '\n+    mkdir -p subdir &&\n+    git -C subdir bisect start &&\n+    git -C subdir bisect good &&\n+    git -C subdir bisect reset\n+'\n+\n test_expect_success 'bisect does not start with only one good' '\n \tgit bisect reset &&\n \tgit bisect start &&\n\nbase-commit: 69986e19ffcfb9af674ae5180689ab7bbf92ed28\n-- \ngitgitgadget\n"},{"id":"408058","messageId":"2f71d0c4-a5de-c22b-9cbe-a9efcb3cd21d@gmail.com","threadId":"54474","inReplyTo":"pull.765.git.1603271344522.gitgitgadget@gmail.com","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2020-10-21T13:41:39Z","receivedAt":"2020-10-21T13:41:44Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Sangeeta\n\nIt's great to see you tackling another patch\n\nOn 21/10/2020 10:09, Sangeeta via GitGitGadget wrote:\n> From: Sangeeta Jain <sangunb09@gmail.com>\n> \n> As `git rebase` was never prevented to run from subdirectory we shouldn't\n> prevent `git bisect` to run from subdirectories.\n\nI'm not sure it's relevant to bisect whether or not rebase can be run \nfrom a subdirectory. What is important is that we want all commands to \nbe able to be run from a subdirectory unless there is a good reason not \nto (and there isn't for bisect)\n\nI'd recommend adding [Outreachy] to the beginning of the first line of \nthe commit message as well.\n\n> This commit removes the\n> restriction on git bisect to run only from top level directory thereby\n> allowing it to run from any subdirectory.\n> \n> Signed-off-by: Sangeeta Jain <sangunb09@gmail.com>\n> ---\n>      [Outreachy] bisect: allow git bisect to run from subdirectory\n>      \n>      As git rebase was never prevented to run from subdirectory we shouldn't\n>      prevent git bisect to run from subdirectories. This commit removes the\n>      restriction on git bisect to run only from top level directory thereby\n>      allowing it to run from any subdirectory.\n>      \n>      Signed-off-by: Sangeeta Jain sangunb09@gmail.com [sangunb09@gmail.com]\n> \n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-765%2Fsangu09%2Fbisect_fix-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-765/sangu09/bisect_fix-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/765\n> \n>   git-bisect.sh               | 1 +\n>   t/t6030-bisect-porcelain.sh | 7 +++++++\n>   2 files changed, 8 insertions(+)\n> \n> diff --git a/git-bisect.sh b/git-bisect.sh\n> index ea7e684ebb..9cd0fa0483 100755\n> --- a/git-bisect.sh\n> +++ b/git-bisect.sh\n> @@ -32,6 +32,7 @@ git bisect run <cmd>...\n>   Please use \"git help bisect\" to get the full man page.'\n>   \n>   OPTIONS_SPEC=\n> +SUBDIRECTORY_OK=Yes\n>   . git-sh-setup\n\n`git bisect run` takes an optional script that is run to determine if \nthe current commit is good or bad. If the script is given with a \nrelative path then we need to make sure it is invoked from the \nsubdirectory that `git bisect run` was started from. As far as I can see \ngit-bisect.sh does not change directory but it would be good to have a \ntest for `git bisect run <cmd>` from a subdirectory.\n\nBest Wishes\n\nPhillip\n\n>   _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'\n> diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh\n> index aa226381be..6b68cc01d0 100755\n> --- a/t/t6030-bisect-porcelain.sh\n> +++ b/t/t6030-bisect-porcelain.sh\n> @@ -49,6 +49,13 @@ test_expect_success 'bisect starts with only one bad' '\n>   \tgit bisect next\n>   '\n>   \n> +test_expect_success 'bisect runs in a subdirectory' '\n> +    mkdir -p subdir &&\n> +    git -C subdir bisect start &&\n> +    git -C subdir bisect good &&\n> +    git -C subdir bisect reset\n> +'\n> +\n>   test_expect_success 'bisect does not start with only one good' '\n>   \tgit bisect reset &&\n>   \tgit bisect start &&\n> \n> base-commit: 69986e19ffcfb9af674ae5180689ab7bbf92ed28\n> \n"},{"id":"408068","messageId":"20201021162044.GB111581@nand.local","threadId":"54474","inReplyTo":"2f71d0c4-a5de-c22b-9cbe-a9efcb3cd21d@gmail.com","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-10-21T16:20:44Z","receivedAt":"2020-10-21T16:20:50Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Oct 21, 2020 at 02:41:39PM +0100, Phillip Wood wrote:\n> Hi Sangeeta\n>\n> It's great to see you tackling another patch\n>\n> On 21/10/2020 10:09, Sangeeta via GitGitGadget wrote:\n> > From: Sangeeta Jain <sangunb09@gmail.com>\n> >\n> > As `git rebase` was never prevented to run from subdirectory we shouldn't\n> > prevent `git bisect` to run from subdirectories.\n>\n> I'm not sure it's relevant to bisect whether or not rebase can be run from a\n> subdirectory. What is important is that we want all commands to be able to\n> be run from a subdirectory unless there is a good reason not to (and there\n> isn't for bisect)\n\nI'm not sure that that's the case: Junio pointed out a while[1] ago that\nwe'd have to answer the question of \"what happens if I'm in a\nsubdirectory that goes away during some point of the bisection?\". I\nthink that you could probably find an answer to that question, but the\nfact that there isn't an obvious one seems to indicate that we're going\ndown the wrong path.\n\nI agree that it would be nice to run bisect from any directory, but it\nmay not be as easy as I'd hope.\n\n[1]: https://lore.kernel.org/git/xmqqpnd359l6.fsf@gitster.c.googlers.com/\n\nThanks,\nTaylor\n"},{"id":"408089","messageId":"xmqqr1pr73ve.fsf@gitster.c.googlers.com","threadId":"54474","inReplyTo":"20201021162044.GB111581@nand.local","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-10-21T19:53:09Z","receivedAt":"2020-10-21T19:53:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau <me@ttaylorr.com> writes:\n\n> I'm not sure that that's the case: Junio pointed out a while[1] ago that\n> we'd have to answer the question of \"what happens if I'm in a\n> subdirectory that goes away during some point of the bisection?\". I\n> think that you could probably find an answer to that question, but the\n> fact that there isn't an obvious one seems to indicate that we're going\n> down the wrong path.\n>\n> I agree that it would be nice to run bisect from any directory, but it\n> may not be as easy as I'd hope.\n\nTrue.\n\nI would not mind all that much a single \"git checkout ancient\" that\nmakes the $cwd go away and confuse the user.  But a bisect session\nwould jump around versions randomly (eh, logarithmically?) and you'd\nend up switching out of a version in a non-existing $cwd to another\nversion that has the directory (created internally by mkdir(2)), and\nI'm fairly certain that your phantom $cwd that is not connected to\nany other filesystem entity and the directory that should be at the\nsame path in the newly checked-out version are different filesystem\nentities.  I'd rather not have to think about the interaction\nbetween git and the system after that point.\n\nThanks.\n"},{"id":"408154","messageId":"nycvar.QRO.7.76.6.2010221042260.56@tvgsbejvaqbjf.bet","threadId":"54474","inReplyTo":"2f71d0c4-a5de-c22b-9cbe-a9efcb3cd21d@gmail.com","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-10-22T08:47:13Z","receivedAt":"2020-10-22T08:47:20Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip,\n\nOn Wed, 21 Oct 2020, Phillip Wood wrote:\n\n> Hi Sangeeta\n>\n> It's great to see you tackling another patch\n>\n> On 21/10/2020 10:09, Sangeeta via GitGitGadget wrote:\n> > From: Sangeeta Jain <sangunb09@gmail.com>\n> >\n> > As `git rebase` was never prevented to run from subdirectory we shouldn't\n> > prevent `git bisect` to run from subdirectories.\n>\n> I'm not sure it's relevant to bisect whether or not rebase can be run from a\n> subdirectory.\n\nThe relevance is this: _iff_ we want to prevent `git bisect` from running\nin a subdirectory under the premise that that subdirectory might need to\nbe removed, then why don't we prevent `git rebase` from running in a\nsubdirectory when that command is equally likely to remove that\nsubdirectory?\n\n> What is important is that we want all commands to be able to be run from\n> a subdirectory unless there is a good reason not to (and there isn't for\n> bisect)\n\nThere is a difference in quality here, though. If you run, say, `git\nfetch` in a subdirectory, or `git commit` or `git show`, there is not the\nsame worry that that subdirectory will go away as with `git bisect`, `git\nrebase`, `git switch`, `git pull` and other commands.\n\n> I'd recommend adding [Outreachy] to the beginning of the first line of\n> the commit message as well.\n\nI am opposed to that. The fact that this comes in via Outreachy is\ninteresting at the moment, for reviewers, but not for posterity (i.e. in\nthe commit that will make it into the commit history).\n\n> > diff --git a/git-bisect.sh b/git-bisect.sh\n> > index ea7e684ebb..9cd0fa0483 100755\n> > --- a/git-bisect.sh\n> > +++ b/git-bisect.sh\n> > @@ -32,6 +32,7 @@ git bisect run <cmd>...\n> >   Please use \"git help bisect\" to get the full man page.'\n> >\n> >   OPTIONS_SPEC=\n> > +SUBDIRECTORY_OK=Yes\n> >   . git-sh-setup\n>\n> `git bisect run` takes an optional script that is run to determine if the\n> current commit is good or bad. If the script is given with a relative path\n> then we need to make sure it is invoked from the subdirectory that `git bisect\n> run` was started from. As far as I can see git-bisect.sh does not change\n> directory but it would be good to have a test for `git bisect run <cmd>` from\n> a subdirectory.\n\nThat's a very good point. We should first add a regression test for\nexactly that use case, and then make sure that it passes.\n\nCiao,\nDscho\n"},{"id":"408155","messageId":"nycvar.QRO.7.76.6.2010221047550.56@tvgsbejvaqbjf.bet","threadId":"54474","inReplyTo":"xmqqr1pr73ve.fsf@gitster.c.googlers.com","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-10-22T08:52:45Z","receivedAt":"2020-10-22T08:52:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 21 Oct 2020, Junio C Hamano wrote:\n\n> Taylor Blau <me@ttaylorr.com> writes:\n>\n> > I'm not sure that that's the case: Junio pointed out a while[1] ago that\n> > we'd have to answer the question of \"what happens if I'm in a\n> > subdirectory that goes away during some point of the bisection?\". I\n> > think that you could probably find an answer to that question, but the\n> > fact that there isn't an obvious one seems to indicate that we're going\n> > down the wrong path.\n> >\n> > I agree that it would be nice to run bisect from any directory, but it\n> > may not be as easy as I'd hope.\n>\n> True.\n>\n> I would not mind all that much a single \"git checkout ancient\" that\n> makes the $cwd go away and confuse the user.  But a bisect session\n> would jump around versions randomly (eh, logarithmically?) and you'd\n> end up switching out of a version in a non-existing $cwd to another\n> version that has the directory (created internally by mkdir(2)), and\n> I'm fairly certain that your phantom $cwd that is not connected to\n> any other filesystem entity and the directory that should be at the\n> same path in the newly checked-out version are different filesystem\n> entities.  I'd rather not have to think about the interaction\n> between git and the system after that point.\n\nBy that token, we should also prevent `git rebase` from running in a\nsubdirectory, but we don't.\n\nBesides, this only becomes an issue when the directory becomes _empty_\n(including untracked files) because we don't remove it otherwise.\n\nI am actually more worried about bisecting between revisions that replace\nthe current subdirectory by a symlink or something.\n\nBut again, this is pretty much precisely the kind of scenario that we\n_already_ allow running into with `git rebase`. So I see little point\nrefusing `git bisect` users to run in a subdirectory.\n\nI know that _I_ often grumble after `git bisect start` fails, then try to\npull out the last remains of my patience and insert `-C ..` or `-C ../..`\nbetween `git` and `bisect` and _still_ get what I want, all while shaking\nmy imaginary fist at `git bisect` for forcing me to type those extra\nkeystrokes.\n\nCiao,\nDscho\n"},{"id":"408158","messageId":"cfe33eef-974d-8ff9-ebb4-d1153abd497c@gmail.com","threadId":"54474","inReplyTo":"nycvar.QRO.7.76.6.2010221047550.56@tvgsbejvaqbjf.bet","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2020-10-22T09:46:56Z","receivedAt":"2020-10-22T09:47:02Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 22/10/2020 09:52, Johannes Schindelin wrote:\n> Hi Junio,\n> \n> On Wed, 21 Oct 2020, Junio C Hamano wrote:\n> \n>> Taylor Blau <me@ttaylorr.com> writes:\n>>\n>>> I'm not sure that that's the case: Junio pointed out a while[1] ago that\n>>> we'd have to answer the question of \"what happens if I'm in a\n>>> subdirectory that goes away during some point of the bisection?\". I\n>>> think that you could probably find an answer to that question, but the\n>>> fact that there isn't an obvious one seems to indicate that we're going\n>>> down the wrong path.\n>>>\n>>> I agree that it would be nice to run bisect from any directory, but it\n>>> may not be as easy as I'd hope.\n>>\n>> True.\n>>\n>> I would not mind all that much a single \"git checkout ancient\" that\n>> makes the $cwd go away and confuse the user.  But a bisect session\n>> would jump around versions randomly (eh, logarithmically?) and you'd\n>> end up switching out of a version in a non-existing $cwd to another\n>> version that has the directory (created internally by mkdir(2)), and\n>> I'm fairly certain that your phantom $cwd that is not connected to\n>> any other filesystem entity and the directory that should be at the\n>> same path in the newly checked-out version are different filesystem\n>> entities.  I'd rather not have to think about the interaction\n>> between git and the system after that point.\n> \n> By that token, we should also prevent `git rebase` from running in a\n> subdirectory, but we don't.\n> \n> Besides, this only becomes an issue when the directory becomes _empty_\n> (including untracked files) because we don't remove it otherwise.\n> \n> I am actually more worried about bisecting between revisions that replace\n> the current subdirectory by a symlink or something.\n> \n> But again, this is pretty much precisely the kind of scenario that we\n> _already_ allow running into with `git rebase`. So I see little point\n> refusing `git bisect` users to run in a subdirectory.\n\nExcept rebase always runs exec commands from the repository root and \nassumes that any relative paths are relative to that directory rather \nthan the one it was started in.\n\ncd t &&\ncat >script <<\\EOF &&\n#!/bin/sh\nexec pwd\nEOF\nchmod u+x script &&\ngit rebase -x ./script HEAD^\n\ngives\n\nExecuting: ./script\nfatal: cannot run ./script: No such file or directory\nwarning: execution failed: ./script\nYou can fix the problem, and then run\n\n   git rebase --continue\n\ngit rebase -x pwd HEAD^\n\nshows\n\n/home/phil/src/git\n\nwhen run from /home/phil/src/git/t\n\nI think both bisect and rebase should be documented as running commands \nfrom the repository root as this is what rebase does and it gets around \nthe missing directory problem.\n\nI'm not sure rebase is doing the right thing with a relative path \nthough. My feeling is it would be less suprising to resolve relative \npaths to the directory where the bisect/rebase is started and store the \nabsolute path. The script may disappear while rebasing but that can \nhappen now if the user points us to a script in a directory that \ndisappears while we're rebasing\n\nBest wishes\n\nPhillip\n\n> I know that _I_ often grumble after `git bisect start` fails, then try to\n> pull out the last remains of my patience and insert `-C ..` or `-C ../..`\n> between `git` and `bisect` and _still_ get what I want, all while shaking\n> my imaginary fist at `git bisect` for forcing me to type those extra\n> keystrokes.\n> \n> Ciao,\n> Dscho\n> \n"},{"id":"408159","messageId":"46b208d8-3741-d528-c833-aea5770a502c@gmail.com","threadId":"54474","inReplyTo":"nycvar.QRO.7.76.6.2010221042260.56@tvgsbejvaqbjf.bet","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2020-10-22T09:52:33Z","receivedAt":"2020-10-22T09:52:39Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Dscho and Sangeeta\n\nOn 22/10/2020 09:47, Johannes Schindelin wrote:\n> Hi Phillip,\n> \n> On Wed, 21 Oct 2020, Phillip Wood wrote:\n> \n>> Hi Sangeeta\n>>\n>> It's great to see you tackling another patch\n>>\n>> On 21/10/2020 10:09, Sangeeta via GitGitGadget wrote:\n>>> From: Sangeeta Jain <sangunb09@gmail.com>\n>>>\n>>> As `git rebase` was never prevented to run from subdirectory we shouldn't\n>>> prevent `git bisect` to run from subdirectories.\n>>\n>> I'm not sure it's relevant to bisect whether or not rebase can be run from a\n>> subdirectory.\n> \n> The relevance is this: _iff_ we want to prevent `git bisect` from running\n> in a subdirectory under the premise that that subdirectory might need to\n> be removed, then why don't we prevent `git rebase` from running in a\n> subdirectory when that command is equally likely to remove that\n> subdirectory?\n\nThat's a good point, I'd completely missed the analogy with `rebase --exec`\n\n>> What is important is that we want all commands to be able to be run from\n>> a subdirectory unless there is a good reason not to (and there isn't for\n>> bisect)\n> \n> There is a difference in quality here, though. If you run, say, `git\n> fetch` in a subdirectory, or `git commit` or `git show`, there is not the\n> same worry that that subdirectory will go away as with `git bisect`, `git\n> rebase`, `git switch`, `git pull` and other commands.\n> \n>> I'd recommend adding [Outreachy] to the beginning of the first line of\n>> the commit message as well.\n> \n> I am opposed to that. The fact that this comes in via Outreachy is\n> interesting at the moment, for reviewers, but not for posterity (i.e. in\n> the commit that will make it into the commit history).\n\nI thought `am` would strip [Outreachy] the same way as it strips [PATCH]\n\n>>> diff --git a/git-bisect.sh b/git-bisect.sh\n>>> index ea7e684ebb..9cd0fa0483 100755\n>>> --- a/git-bisect.sh\n>>> +++ b/git-bisect.sh\n>>> @@ -32,6 +32,7 @@ git bisect run <cmd>...\n>>>    Please use \"git help bisect\" to get the full man page.'\n>>>\n>>>    OPTIONS_SPEC=\n>>> +SUBDIRECTORY_OK=Yes\n>>>    . git-sh-setup\n>>\n>> `git bisect run` takes an optional script that is run to determine if the\n>> current commit is good or bad. If the script is given with a relative path\n>> then we need to make sure it is invoked from the subdirectory that `git bisect\n>> run` was started from. As far as I can see git-bisect.sh does not change\n>> directory but it would be good to have a test for `git bisect run <cmd>` from\n>> a subdirectory.\n> \n> That's a very good point. We should first add a regression test for\n> exactly that use case, and then make sure that it passes.\n\nThough I'm now wondering if we should be running the command from the \nrepository root directory like rebase[1]\n\nBest Wishes\n\nPhillip\n\n[1] \nhttps://lore.kernel.org/git/cfe33eef-974d-8ff9-ebb4-d1153abd497c@gmail.com\n\n> Ciao,\n> Dscho\n> \n"},{"id":"408173","messageId":"xmqq7drinqxv.fsf@gitster.c.googlers.com","threadId":"54474","inReplyTo":"cfe33eef-974d-8ff9-ebb4-d1153abd497c@gmail.com","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-10-22T16:52:44Z","receivedAt":"2020-10-22T16:52:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood <phillip.wood123@gmail.com> writes:\n\n> I think both bisect and rebase should be documented as running\n> commands from the repository root as this is what rebase does and it\n> gets around the missing directory problem.\n>\n> I'm not sure rebase is doing the right thing with a relative path\n> though. My feeling is it would be less suprising to resolve relative \n> paths to the directory where the bisect/rebase is started and store\n> the absolute path. The script may disappear while rebasing but that\n> can happen now if the user points us to a script in a directory that \n> disappears while we're rebasing\n\nIf a step in the rebase sequence makes a directory disappear (or\nturns a directory into a file), and the command given by -x is in\nthe directory (it is immaterial if it is given as relative or full\npathname from the command line), hopefully the step of the rebase\nsequence that would lose the directory would error out, in order to\nprevent an untracked but not ignored file from getting clobbered.\n\nEven before speculating such an \"advanced\" mode of operation, do we\nknow that rebasing a history that makes a directory disappear and\nreappear work?\n\nFor example, if there is a history like this:\n\n    - commit #0: an empty tree\n    - commit #1: adds a file D/F\n    - commit #2: moves the file D/F to F (i.e. the toplevel)\n    - commit #3: moves the file F to D (i.e. D becomes a file)\n    - commit #4: moves the file D to E\n    - commit #5: moves the file E to D/E (i.e. D becomes a directory again)\n\ndoes it do what expect it to do if we replay the history c0..c5 on\ntop of a comit that records an empty tree if we start the rebase\nin an empty directory D?\n\nHere is what I tried in an empty directory, and the last \"ls -la\"\nshows an empty directory, even if you try \"ls -la D\" from a separate\nshell after everything is done, you'd see a file D/E there.  If a\nplatform exists that does not allow removing a directory that is the\n$cwd of any process, I would not be surprised if the whole thing\nfailed in a mysterious (to the end user) way.\n\n#!/bin/sh\ntest -d .git && exit ;# safety\nrm -fr D E F\ngit init\n\ngit commit --allow-empty -m 'an empty tree'\ngit tag commit0\n\nmkdir D && >D/F && git add D/F\ngit commit -m 'add a file D/F'\n\ngit mv D/F F && git commit -m 'move D/F to F'\nrm -rf D\n\ngit mv F D && git commit -m 'move F to D'\n\ngit mv D E && git commit -m 'move D to E'\n\nmkdir D && git mv E D/E && git commit -m 'move E to D/E'\n\ngit tag commit5\n\necho history made\n\ngit checkout --orphan rebuilt\ngit rm -r -f .\ngit commit --allow-empty -m 'another empty tree'\n\nmkdir D\ncd D\n\ngit rebase --onto HEAD commit0 commit5^0\nls -la\n"},{"id":"408174","messageId":"xmqqzh4embt5.fsf@gitster.c.googlers.com","threadId":"54474","inReplyTo":"46b208d8-3741-d528-c833-aea5770a502c@gmail.com","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-10-22T17:04:54Z","receivedAt":"2020-10-22T17:05:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood <phillip.wood123@gmail.com> writes:\n\n>> The relevance is this: _iff_ we want to prevent `git bisect` from\n>> running\n>> in a subdirectory under the premise that that subdirectory might need to\n>> be removed, then why don't we prevent `git rebase` from running in a\n>> subdirectory when that command is equally likely to remove that\n>> subdirectory?\n>\n> That's a good point, I'd completely missed the analogy with `rebase --exec`\n\nI concur.  Perhaps we should make rebase a bit more careful.\n"},{"id":"408220","messageId":"CAHjREB7+3QtPw6X33GEB8SiDjSfvNhb15+_rpy=McmqBdcMebQ@mail.gmail.com","threadId":"54474","inReplyTo":"xmqq7drinqxv.fsf@gitster.c.googlers.com","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Sangeeta NB","fromEmail":"sangunb09@gmail.com","sentAt":"2020-10-23T10:59:52Z","receivedAt":"2020-10-23T11:00:07Z","isPatch":true,"sender":{"key":"sangunb09@gmail.com","avatar":"https://avatars.githubusercontent.com/u/64827599?v=4"},"body":"Hey everyone,\n\nSorry for participating in the discussions so late. I thought I need\nto have enough knowledge first before participating.\n\n>\n> If a step in the rebase sequence makes a directory disappear (or\n> turns a directory into a file), and the command given by -x is in\n> the directory (it is immaterial if it is given as relative or full\n> pathname from the command line), hopefully the step of the rebase\n> sequence that would lose the directory would error out, in order to\n> prevent an untracked but not ignored file from getting clobbered.\n>\n> Even before speculating such an \"advanced\" mode of operation, do we\n> know that rebasing a history that makes a directory disappear and\n> reappear work?\n>\n\nYes, I agree. We need to make some changes in `git rebase` to make it\nwork from the subdirectory, but that doesn't mean that we should\ncompletely restrict it from running in the subdirectory, and the same\nfollows for `git bisect`.\n\nWhat I think that we should allow `git bisect` from any subdirectory.\nWe can add some warnings in case if there's some error while bisecting\nfrom a subdirectory in the same way by which we handle the errors in\n`git rebase` and let the user decide whether he still wants to\ncontinue bisecting from that subdirectory or abort it and run it from\nthe top-level directory.\n"},{"id":"408241","messageId":"10d10f36-0bb6-614f-2602-c122bab42b7c@gmail.com","threadId":"54474","inReplyTo":"xmqq7drinqxv.fsf@gitster.c.googlers.com","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2020-10-23T15:18:07Z","receivedAt":"2020-10-23T15:18:12Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Junio\n\nOn 22/10/2020 17:52, Junio C Hamano wrote:\n> Phillip Wood <phillip.wood123@gmail.com> writes:\n> \n>> I think both bisect and rebase should be documented as running\n>> commands from the repository root as this is what rebase does and it\n>> gets around the missing directory problem.\n>>\n>> I'm not sure rebase is doing the right thing with a relative path\n>> though. My feeling is it would be less suprising to resolve relative\n>> paths to the directory where the bisect/rebase is started and store\n>> the absolute path. The script may disappear while rebasing but that\n>> can happen now if the user points us to a script in a directory that\n>> disappears while we're rebasing\n> \n> If a step in the rebase sequence makes a directory disappear (or\n> turns a directory into a file), and the command given by -x is in\n> the directory (it is immaterial if it is given as relative or full\n> pathname from the command line), hopefully the step of the rebase\n> sequence that would lose the directory would error out, in order to\n> prevent an untracked but not ignored file from getting clobbered.\n> \n> Even before speculating such an \"advanced\" mode of operation, do we\n> know that rebasing a history that makes a directory disappear and\n> reappear work?\n> \n> For example, if there is a history like this:\n> \n>      - commit #0: an empty tree\n>      - commit #1: adds a file D/F\n>      - commit #2: moves the file D/F to F (i.e. the toplevel)\n>      - commit #3: moves the file F to D (i.e. D becomes a file)\n>      - commit #4: moves the file D to E\n>      - commit #5: moves the file E to D/E (i.e. D becomes a directory again)\n> \n> does it do what expect it to do if we replay the history c0..c5 on\n> top of a comit that records an empty tree if we start the rebase\n> in an empty directory D?\n> \n> Here is what I tried in an empty directory, and the last \"ls -la\"\n> shows an empty directory, even if you try \"ls -la D\" from a separate\n> shell after everything is done, you'd see a file D/E there.  If a\n> platform exists that does not allow removing a directory that is the\n> $cwd of any process, I would not be surprised if the whole thing\n> failed in a mysterious (to the end user) way.\n\nThanks for the demonstration. There are several other commands \n(checkout, merge, cherry-pick, reset --hard, revert and maybe apply and \nam?) that can remove the current working directory of the shell that \nthey are run from when they are invoked from a subdirectory. Rebase and \ncherry-pick/revert differ from checkout and merge in that they can \npotentially delete and then recreate the directory they are invoked from \nwhich adds another layer of confusion but having a checkout remove the \ndirectory it is invoked from isn't great.\n\nOne way to avoid it would be to stop all of these commands from being \nrun from a subdirectory and also object if they are run as anything like \n`git -C .. <cmd>` but that would be very restrictive.\n\nThinking out loud maybe another possibility would be to error out if the \ncommand would remove the directory git was invoked from. I've not looked \ninto it but wonder if these cases could be covered by a checks in \nunpack_trees() and apply.c but I don't know how realistic that is. (I've \na feeling Elijah mentioned his ort plans don't use unpack_trees() which \nwould complicate things)\n\nAll in all I'm not sure rebase is that much worse than checkout or merge \nwhen it comes to removing the directory it is invoked from. If this is \nsomething we care about a general solution might be better than just \nstopping rebase and bisect from being run from a subdirectory.\n\nBest Wishes\n\nPhillip\n\n> #!/bin/sh\n> test -d .git && exit ;# safety\n> rm -fr D E F\n> git init\n> \n> git commit --allow-empty -m 'an empty tree'\n> git tag commit0\n> \n> mkdir D && >D/F && git add D/F\n> git commit -m 'add a file D/F'\n> \n> git mv D/F F && git commit -m 'move D/F to F'\n> rm -rf D\n> \n> git mv F D && git commit -m 'move F to D'\n> \n> git mv D E && git commit -m 'move D to E'\n> \n> mkdir D && git mv E D/E && git commit -m 'move E to D/E'\n> \n> git tag commit5\n> \n> echo history made\n> \n> git checkout --orphan rebuilt\n> git rm -r -f .\n> git commit --allow-empty -m 'another empty tree'\n> \n> mkdir D\n> cd D\n> \n> git rebase --onto HEAD commit0 commit5^0\n> ls -la\n> \n"},{"id":"408245","messageId":"xmqqeelphrsp.fsf@gitster.c.googlers.com","threadId":"54474","inReplyTo":"CAHjREB7+3QtPw6X33GEB8SiDjSfvNhb15+_rpy=McmqBdcMebQ@mail.gmail.com","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-10-23T15:43:02Z","receivedAt":"2020-10-23T15:43:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sangeeta NB <sangunb09@gmail.com> writes:\n\n> Yes, I agree. We need to make some changes in `git rebase` to make it\n> work from the subdirectory, but that doesn't mean that we should\n> completely restrict it from running in the subdirectory, and the same\n> follows for `git bisect`.\n\nYou actually don't have to make \"bisect\" work from the subdirectory.\n\nYou instead can detect the case where your $cwd may be made to\ndisappear, and allow \"git bisect\" to continue if you are certain\nthat you are not in the funny situation.  You need to protect the\nuser from funny situation by refusing to run from a subdirectory\nonly when needed.\n\nBesides, as Phillip mentioned, there is a big difference between two\ncommands, isn't it?\n\n\"git rebase\" would ask for help to the end-user by returning the\ncontrol when anything goes wrong (e.g. it may not be able to replay\na commit while the user is sitting in a directory that has already\ngone), but \"git bisect run\" would just interpret any failure, not\njust the ones that are caused by genuine test failure but caused by\n$cwd going away, as \"we saw a bad revision\".  It would cause a lot\nof wasted cycles, instead of immediately stopping when there is\ntrouble.  So the first thing that has to happen if we want to allow\n\"bisect\" to run from anywhere is to teach it to detect when the $cwd\nwent away, and stop to give control back to the user to deal with\nthe situation (it might be the matter of \"cd /path/to/top\" at that\npoint), instead of blindly continuing.  Only after that is in place,\nwe can safely allow it to start from a subdirectory.\n\nThanks.\n"},{"id":"408246","messageId":"nycvar.QRO.7.76.6.2010231036180.56@tvgsbejvaqbjf.bet","threadId":"54474","inReplyTo":"xmqqzh4embt5.fsf@gitster.c.googlers.com","subject":"Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-10-23T08:37:24Z","receivedAt":"2020-10-23T15:48:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 22 Oct 2020, Junio C Hamano wrote:\n\n> Phillip Wood <phillip.wood123@gmail.com> writes:\n>\n> >> The relevance is this: _iff_ we want to prevent `git bisect` from\n> >> running\n> >> in a subdirectory under the premise that that subdirectory might need to\n> >> be removed, then why don't we prevent `git rebase` from running in a\n> >> subdirectory when that command is equally likely to remove that\n> >> subdirectory?\n> >\n> > That's a good point, I'd completely missed the analogy with `rebase --exec`\n>\n> I concur.  Perhaps we should make rebase a bit more careful.\n\nThat might be a rabbit hole that's a little too deep. If we want to make\nrebase a bit more careful, we then also must make `git -C ..` more\ncareful. And `git -C ../..`...\n\nI am fairly certain that I don't want to go there.\n\nCiao,\nDscho\n"}]}