Elijah Newren [off-list ref] writes:
quoted
Why does Git have to delete and then create again the directory when it
is already there?
This isn't a big issue, but it is very odd that git deletes the working
directory.
It was deleted by the rebase operation, because rebase (currently)
works by first checking out the target commit onto which it will apply
all your local patches. That target didn't have the directory; the
directory was added by your local patches. So checking out that
commit necessarily deletes the directory. Then rebase applies each of
your local patches, one by one, updating the working directory as it
applies them. Since your local patches create that directory, it gets
re-created by this process.
This is one of the reasons why "rebase" (especially "rebase -i") may
want to insist starting at the top-level of the working tree, like
"git bisect" does. Because running the command from a subdirectory
works most of the time until it doesn't, people tend to complain why
they should go up to the top-level before they can run the command.
And this is why---it causes end-user confusion.
On 8/29/21 5:07 PM, Junio C Hamano wrote:
This is one of the reasons why "rebase" (especially "rebase -i") may
want to insist starting at the top-level of the working tree, like
"git bisect" does. Because running the command from a subdirectory
works most of the time until it doesn't, people tend to complain why
they should go up to the top-level before they can run the command.
And this is why---it causes end-user confusion.
But there's no confusion here - git doesn't have to delete the directory
and recreate it, but it does it anyway.
So this is just a bug that git disturbs users more than it should.
Yuri
On Sun, Aug 29, 2021 at 5:07 PM Junio C Hamano [off-list ref] wrote:
Elijah Newren [off-list ref] writes:
quoted
quoted
Why does Git have to delete and then create again the directory when it
is already there?
This isn't a big issue, but it is very odd that git deletes the working
directory.
It was deleted by the rebase operation, because rebase (currently)
works by first checking out the target commit onto which it will apply
all your local patches. That target didn't have the directory; the
directory was added by your local patches. So checking out that
commit necessarily deletes the directory. Then rebase applies each of
your local patches, one by one, updating the working directory as it
applies them. Since your local patches create that directory, it gets
re-created by this process.
This is one of the reasons why "rebase" (especially "rebase -i") may
want to insist starting at the top-level of the working tree, like
"git bisect" does. Because running the command from a subdirectory
works most of the time until it doesn't, people tend to complain why
they should go up to the top-level before they can run the command.
And this is why---it causes end-user confusion.
Makes sense to me; I'll submit a patch.