On Fri, Aug 27, 2021 at 8:49 PM Yuri <yuri@xxxxxxxxx> 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
