Git re-creates newly added directory when it is pushed

Git re-creates newly added directory when it is pushed

[Yuri]

I create a new directory, add it to git and push it.

After push it says: Unable to read current working directory: No such 
file or directory


[yuri@yv /usr/ports/math/stanmath]$ git pull -r && git push origin 
--push-option=confirm-author
remote: Enumerating objects: 283, done.
remote: Counting objects: 100% (283/283), done.
remote: Compressing objects: 100% (187/187), done.
remote: Total 188 (delta 94), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (188/188), 29.37 KiB | 578.00 KiB/s, done.
Resolving deltas: 100% (94/94), completed with 50 local objects.
 From ssh://gitrepo.freebsd.org/ports
    80469139f77f..cf8b94761057  main       -> origin/main
Successfully rebased and updated refs/heads/main.
fatal: Unable to read current working directory: No such file or directory


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.


FreeBSD 13.



Yuri

Re: Git re-creates newly added directory when it is pushed

[Elijah Newren]

On Fri, Aug 27, 2021 at 8:49 PM Yuri <yuri@rawbw.com> wrote:
>
> I create a new directory, add it to git and push it.

And I think you left out that you cd'ed into the directory as well
before running your `git pull --rebase`.

> After push it says: Unable to read current working directory: No such
> file or directory
>
> [yuri@yv /usr/ports/math/stanmath]$ git pull -r && git push origin
> --push-option=confirm-author
> remote: Enumerating objects: 283, done.
> remote: Counting objects: 100% (283/283), done.
> remote: Compressing objects: 100% (187/187), done.
> remote: Total 188 (delta 94), reused 3 (delta 0), pack-reused 0
> Receiving objects: 100% (188/188), 29.37 KiB | 578.00 KiB/s, done.
> Resolving deltas: 100% (94/94), completed with 50 local objects.
>  From ssh://gitrepo.freebsd.org/ports
>     80469139f77f..cf8b94761057  main       -> origin/main
> Successfully rebased and updated refs/heads/main.
> fatal: Unable to read current working directory: No such file or directory
>
>
> 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.

And since your current working directory was inside that directory
that was deleted, later commands get all confused by the current
working directory not existing.

Incidentally, rebase works like this because the default merge
backend, recursive, intrinsically works with the working copy and
updates it as it goes.  Rebase could theoretically redo each of the
merges without updating the working copy, assuming there are no
conflicts, and then checkout the new target commit at the end.  That'd
require a new merge backend that allowed merging without updating the
working copy, though, which was only recently added (see the Git 2.33
release notes).  Rebase has not yet been updated to take advantage of
that capability; there's a good chunk of work involved to try to do
so.  And even when it does, you could still hit this problem if rebase
hit a conflict on a local patch where the relevant directory did not
yet exist.


Hope that helps,
Elijah

Re: Git re-creates newly added directory when it is pushed

[Yuri]

On 8/27/21 10:33 PM, Elijah Newren wrote:
> And I think you left out that you cd'ed into the directory as well
> before running your `git pull --rebase`.


Yes, this is how people normally work with this repository. They change 
individual directories (ports are like sub-projects) and commit them 
while staying in them.


Yuri

Re: Git re-creates newly added directory when it is pushed

[Junio C Hamano]

Elijah Newren <newren@gmail.com> writes:

>> 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.

Re: Git re-creates newly added directory when it is pushed

[Yuri]

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

Re: Git re-creates newly added directory when it is pushed

[Junio C Hamano]

Yuri <yuri@rawbw.com> writes:

> 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.

No, this is an example that users usually can be unaware of the
reason why it is a bad idea to start from subdirectories.

As Elijah explained, if a multi-step rebase had to stop and ask help
from the user to resolve conflict _before_ the step that creates the
user's current directory, it would leave the user in a confusing
situation where the user thinks is in a directory but that directory
does not yet exist in the filesystem.

Re: Git re-creates newly added directory when it is pushed

[Philip Oakley]

On 30/08/2021 01:29, Junio C Hamano wrote:
> Yuri <yuri@rawbw.com> writes:
>
>> 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.
> No, this is an example that users usually can be unaware of the
> reason why it is a bad idea to start from subdirectories.
>
> As Elijah explained, if a multi-step rebase had to stop and ask help
> from the user to resolve conflict _before_ the step that creates the
> user's current directory, it would leave the user in a confusing
> situation where the user thinks is in a directory but that directory
> does not yet exist in the filesystem.
Does this end up being a documentation issue?

e.g. Users should start at top-level because..
or Note, if the current directory is removed at some step during the
rebase then..

Often folk do read the documentation as a lest resort..
-- 
Philip

Re: Git re-creates newly added directory when it is pushed

[Elijah Newren]

On Sun, Aug 29, 2021 at 5:07 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> >> 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.

Re: Git re-creates newly added directory when it is pushed

[Junio C Hamano]

Elijah Newren <newren@gmail.com> writes:

>> 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.

Well, but not too hastily.

It is one thing to be firm and resist those who want to loosen "git
bisect" to allow it to start in a subdirectory, in order to keep
protecting the innocent who are already protected with the current
safeguard from confusion.

It is entirely a different thing to tighten "git rebase"
retroactively to break those who are used to see the command start
in a subdirectory.

The potential confusion that is caused may be the same between
commands, but either change can potentially hurt existing users.

I hope your patch would serve as a good discussion starter.  We may
end up loosening "git bisect" to expose our users to possible
confusion, the same one that already exists for users of "git
rebase", in the name of consistency, and it might even turn out to
be a good change.  Or not.

In any case, it would be a good opportunity to force people
thoroughly think things through.

Thanks.