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

On Fri, Aug 27, 2021 at 8:49 PM Yuri [off-list ref] 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