On 22/10/2020 09:52, Johannes Schindelin wrote:
Hi Junio,
On Wed, 21 Oct 2020, Junio C Hamano wrote:
Taylor Blau <me@xxxxxxxxxxxx> writes:
I'm not sure that that's the case: Junio pointed out a while[1] ago that
we'd have to answer the question of "what happens if I'm in a
subdirectory that goes away during some point of the bisection?". I
think that you could probably find an answer to that question, but the
fact that there isn't an obvious one seems to indicate that we're going
down the wrong path.
I agree that it would be nice to run bisect from any directory, but it
may not be as easy as I'd hope.
True.
I would not mind all that much a single "git checkout ancient" that
makes the $cwd go away and confuse the user. But a bisect session
would jump around versions randomly (eh, logarithmically?) and you'd
end up switching out of a version in a non-existing $cwd to another
version that has the directory (created internally by mkdir(2)), and
I'm fairly certain that your phantom $cwd that is not connected to
any other filesystem entity and the directory that should be at the
same path in the newly checked-out version are different filesystem
entities. I'd rather not have to think about the interaction
between git and the system after that point.
By that token, we should also prevent `git rebase` from running in a
subdirectory, but we don't.
Besides, this only becomes an issue when the directory becomes _empty_
(including untracked files) because we don't remove it otherwise.
I am actually more worried about bisecting between revisions that replace
the current subdirectory by a symlink or something.
But again, this is pretty much precisely the kind of scenario that we
_already_ allow running into with `git rebase`. So I see little point
refusing `git bisect` users to run in a subdirectory.
Except rebase always runs exec commands from the repository root and
assumes that any relative paths are relative to that directory rather
than the one it was started in.
cd t &&
cat >script <<\EOF &&
#!/bin/sh
exec pwd
EOF
chmod u+x script &&
git rebase -x ./script HEAD^
gives
Executing: ./script
fatal: cannot run ./script: No such file or directory
warning: execution failed: ./script
You can fix the problem, and then run
git rebase --continue
git rebase -x pwd HEAD^
shows
/home/phil/src/git
when run from /home/phil/src/git/t
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
Best wishes
Phillip
I know that _I_ often grumble after `git bisect start` fails, then try to
pull out the last remains of my patience and insert `-C ..` or `-C ../..`
between `git` and `bisect` and _still_ get what I want, all while shaking
my imaginary fist at `git bisect` for forcing me to type those extra
keystrokes.
Ciao,
Dscho
