* Git re-creates newly added directory when it is pushed @ 2021-08-28 3:46 Yuri 2021-08-28 5:33 ` Elijah Newren 0 siblings, 1 reply; 9+ messages in thread From: Yuri @ 2021-08-28 3:46 UTC (permalink / raw) To: Git Mailing List 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Git re-creates newly added directory when it is pushed 2021-08-28 3:46 Git re-creates newly added directory when it is pushed Yuri @ 2021-08-28 5:33 ` Elijah Newren 2021-08-28 5:43 ` Yuri 2021-08-30 0:07 ` Junio C Hamano 0 siblings, 2 replies; 9+ messages in thread From: Elijah Newren @ 2021-08-28 5:33 UTC (permalink / raw) To: Yuri; +Cc: Git Mailing List 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Git re-creates newly added directory when it is pushed 2021-08-28 5:33 ` Elijah Newren @ 2021-08-28 5:43 ` Yuri 2021-08-30 0:07 ` Junio C Hamano 1 sibling, 0 replies; 9+ messages in thread From: Yuri @ 2021-08-28 5:43 UTC (permalink / raw) To: Elijah Newren; +Cc: Git Mailing List 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Git re-creates newly added directory when it is pushed 2021-08-28 5:33 ` Elijah Newren 2021-08-28 5:43 ` Yuri @ 2021-08-30 0:07 ` Junio C Hamano 2021-08-30 0:14 ` Yuri 2021-08-31 2:15 ` Elijah Newren 1 sibling, 2 replies; 9+ messages in thread From: Junio C Hamano @ 2021-08-30 0:07 UTC (permalink / raw) To: Elijah Newren; +Cc: Yuri, Git Mailing List 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Git re-creates newly added directory when it is pushed 2021-08-30 0:07 ` Junio C Hamano @ 2021-08-30 0:14 ` Yuri 2021-08-30 0:29 ` Junio C Hamano 2021-08-31 2:15 ` Elijah Newren 1 sibling, 1 reply; 9+ messages in thread From: Yuri @ 2021-08-30 0:14 UTC (permalink / raw) To: Junio C Hamano, Elijah Newren; +Cc: Git Mailing List 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Git re-creates newly added directory when it is pushed 2021-08-30 0:14 ` Yuri @ 2021-08-30 0:29 ` Junio C Hamano 2021-08-30 9:27 ` Philip Oakley 0 siblings, 1 reply; 9+ messages in thread From: Junio C Hamano @ 2021-08-30 0:29 UTC (permalink / raw) To: Yuri; +Cc: Elijah Newren, Git Mailing List 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Git re-creates newly added directory when it is pushed 2021-08-30 0:29 ` Junio C Hamano @ 2021-08-30 9:27 ` Philip Oakley 0 siblings, 0 replies; 9+ messages in thread From: Philip Oakley @ 2021-08-30 9:27 UTC (permalink / raw) To: Junio C Hamano, Yuri; +Cc: Elijah Newren, Git Mailing List 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Git re-creates newly added directory when it is pushed 2021-08-30 0:07 ` Junio C Hamano 2021-08-30 0:14 ` Yuri @ 2021-08-31 2:15 ` Elijah Newren 2021-08-31 4:41 ` Junio C Hamano 1 sibling, 1 reply; 9+ messages in thread From: Elijah Newren @ 2021-08-31 2:15 UTC (permalink / raw) To: Junio C Hamano; +Cc: Yuri, Git Mailing List 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Git re-creates newly added directory when it is pushed 2021-08-31 2:15 ` Elijah Newren @ 2021-08-31 4:41 ` Junio C Hamano 0 siblings, 0 replies; 9+ messages in thread From: Junio C Hamano @ 2021-08-31 4:41 UTC (permalink / raw) To: Elijah Newren; +Cc: Yuri, Git Mailing List 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-08-31 4:41 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-28 3:46 Git re-creates newly added directory when it is pushed Yuri 2021-08-28 5:33 ` Elijah Newren 2021-08-28 5:43 ` Yuri 2021-08-30 0:07 ` Junio C Hamano 2021-08-30 0:14 ` Yuri 2021-08-30 0:29 ` Junio C Hamano 2021-08-30 9:27 ` Philip Oakley 2021-08-31 2:15 ` Elijah Newren 2021-08-31 4:41 ` Junio C Hamano
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).