Hi Junio
On 22/10/2020 17:52, Junio C Hamano wrote:
Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
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.
Thanks for the demonstration. There are several other commands
(checkout, merge, cherry-pick, reset --hard, revert and maybe apply and
am?) that can remove the current working directory of the shell that
they are run from when they are invoked from a subdirectory. Rebase and
cherry-pick/revert differ from checkout and merge in that they can
potentially delete and then recreate the directory they are invoked from
which adds another layer of confusion but having a checkout remove the
directory it is invoked from isn't great.
One way to avoid it would be to stop all of these commands from being
run from a subdirectory and also object if they are run as anything like
`git -C .. <cmd>` but that would be very restrictive.
Thinking out loud maybe another possibility would be to error out if the
command would remove the directory git was invoked from. I've not looked
into it but wonder if these cases could be covered by a checks in
unpack_trees() and apply.c but I don't know how realistic that is. (I've
a feeling Elijah mentioned his ort plans don't use unpack_trees() which
would complicate things)
All in all I'm not sure rebase is that much worse than checkout or merge
when it comes to removing the directory it is invoked from. If this is
something we care about a general solution might be better than just
stopping rebase and bisect from being run from a subdirectory.
Best Wishes
Phillip
#!/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
