Re: [PATCH][OUTREACHY] bisect: allow `git bisect` to run from subdirectory

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 22, 2020, 16:52 UTC
Message-ID: <xmqq7drinqxv.fsf@gitster.c.googlers.com>
In-Reply-To: <cfe33eef-974d-8ff9-ebb4-d1153abd497c@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 10 quoted lines

> I think both bisect and rebase should be documented as running
> commands from the repository root as this is what rebase does and it
> gets around the missing directory problem.
>
> I'm not sure rebase is doing the right thing with a relative path
> though. My feeling is it would be less suprising to resolve relative 
> paths to the directory where the bisect/rebase is started and store
> the absolute path. The script may disappear while rebasing but that
> can happen now if the user points us to a script in a directory that 
> disappears while we're rebasing

If a step in the rebase sequence makes a directory disappear (or turns a directory into a file), and the command given by -x is in the directory (it is immaterial if it is given as relative or full pathname from the command line), hopefully the step of the rebase sequence that would lose the directory would error out, in order to prevent an untracked but not ignored file from getting clobbered.

Even before speculating such an "advanced" mode of operation, do we know that rebasing a history that makes a directory disappear and reappear work?

For example, if there is a history like this:

    - commit #0: an empty tree
    - commit #1: adds a file D/F
    - commit #2: moves the file D/F to F (i.e. the toplevel)
    - commit #3: moves the file F to D (i.e. D becomes a file)
    - commit #4: moves the file D to E
    - commit #5: moves the file E to D/E (i.e. D becomes a directory again)

does it do what expect it to do if we replay the history c0..c5 on top of a comit that records an empty tree if we start the rebase in an empty directory D?

Here is what I tried in an empty directory, and the last "ls -la" shows an empty directory, even if you try "ls -la D" from a separate shell after everything is done, you'd see a file D/E there. If a platform exists that does not allow removing a directory that is the $cwd of any process, I would not be surprised if the whole thing failed in a mysterious (to the end user) way.

#!/bin/sh test -d .git && exit ;# safety rm -fr D E F git init

git commit --allow-empty -m 'an empty tree' git tag commit0

mkdir D && >D/F && git add D/F git commit -m 'add a file D/F'

git mv D/F F && git commit -m 'move D/F to F' rm -rf D

git mv F D && git commit -m 'move F to D'

git mv D E && git commit -m 'move D to E'

mkdir D && git mv E D/E && git commit -m 'move E to D/E'

git tag commit5

echo history made

git checkout --orphan rebuilt git rm -r -f . git commit --allow-empty -m 'another empty tree'

mkdir D cd D

git rebase --onto HEAD commit0 commit5^0 ls -la