Re: [PATCH] bisect: remove root directory restriction for git bisect

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

Hi Gábor,

On Sun, 22 Mar 2020, SZEDER Gábor wrote:

> On Sun, Mar 22, 2020 at 09:15:47AM +0000, Sheikh hamza via GitGitGadget wrote:
> > From: sheikh hamza <sheikhhamza012@gmail.com>
> >
> > the git bisect
> >     command should be able to run from inside any
> >     subdirectory
>
> Why should 'git bisect' be able to run from inside any subdirectory
> (of the working tree, I presume)?

Because other commands also allow the user to run in a subdirectory. For
example, `git rebase`, `git checkout`, `git cherry-pick`, etc

> In particular, what happens, if someone starts 'git bisect' from within
> 'subdir/', and 'git bisect' then checks out an old commit, where said
> 'subdir/' didn't exist?  What happens, if the user runs 'git bisect run
> ./script' from within 'subdir/', and that 'subdir/' doesn't exist in
> that old commit?

The same that happens if that situation arises in `git rebase` or `git
checkout`: the directory is removed unless it is not empty (i.e. if there
are untracked files in the directory, or submodules).

> What happens, if 'subdir' does exists in that old commit, but it's a
> file, not a directory?  What happens, if all this is on Windows?

On Windows, the directory is not deletable, of course, and the same thing
happens as if an untracked file is still in that directory: it is not
deleted.

> >  git-bisect.sh            | 1 +
> >  t/perf/bisect_regression | 6 ++----
> >  2 files changed, 3 insertions(+), 4 deletions(-)

The most obvious problem with this patch is that it is not accompanied by
a regression test that documents and verifies the intended behavior.

Ciao,
Dscho