{"thread":{"id":"56391","subject":"Git re-creates newly added directory when it is pushed","startedAt":"2021-08-28T03:46:16Z","lastAt":"2021-08-31T04:41:19Z","messageCount":9,"participants":["Yuri","Elijah Newren","Junio C Hamano","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"434004","messageId":"c0557284-8f82-76cc-8c47-0b1bc9f2ce5a@rawbw.com","threadId":"56391","inReplyTo":null,"subject":"Git re-creates newly added directory when it is pushed","fromName":"Yuri","fromEmail":"yuri@rawbw.com","sentAt":"2021-08-28T03:46:08Z","receivedAt":"2021-08-28T03:46:16Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"I create a new directory, add it to git and push it.\n\nAfter push it says: Unable to read current working directory: No such \nfile or directory\n\n\n[yuri@yv /usr/ports/math/stanmath]$ git pull -r && git push origin \n--push-option=confirm-author\nremote: Enumerating objects: 283, done.\nremote: Counting objects: 100% (283/283), done.\nremote: Compressing objects: 100% (187/187), done.\nremote: Total 188 (delta 94), reused 3 (delta 0), pack-reused 0\nReceiving objects: 100% (188/188), 29.37 KiB | 578.00 KiB/s, done.\nResolving deltas: 100% (94/94), completed with 50 local objects.\n From ssh://gitrepo.freebsd.org/ports\n    80469139f77f..cf8b94761057  main       -> origin/main\nSuccessfully rebased and updated refs/heads/main.\nfatal: Unable to read current working directory: No such file or directory\n\n\nWhy does Git have to delete and then create again the directory when it \nis already there?\n\n\nThis isn't a big issue, but it is very odd that git deletes the working \ndirectory.\n\n\nFreeBSD 13.\n\n\n\nYuri\n\n"},{"id":"434009","messageId":"CABPp-BFwvDY6-6pQ2MSPzAGafONjTEMNUkLwuRuQCJ_wx2ns2w@mail.gmail.com","threadId":"56391","inReplyTo":"c0557284-8f82-76cc-8c47-0b1bc9f2ce5a@rawbw.com","subject":"Re: Git re-creates newly added directory when it is pushed","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-08-28T05:33:10Z","receivedAt":"2021-08-28T05:33:24Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Aug 27, 2021 at 8:49 PM Yuri <yuri@rawbw.com> wrote:\n>\n> I create a new directory, add it to git and push it.\n\nAnd I think you left out that you cd'ed into the directory as well\nbefore running your `git pull --rebase`.\n\n> After push it says: Unable to read current working directory: No such\n> file or directory\n>\n> [yuri@yv /usr/ports/math/stanmath]$ git pull -r && git push origin\n> --push-option=confirm-author\n> remote: Enumerating objects: 283, done.\n> remote: Counting objects: 100% (283/283), done.\n> remote: Compressing objects: 100% (187/187), done.\n> remote: Total 188 (delta 94), reused 3 (delta 0), pack-reused 0\n> Receiving objects: 100% (188/188), 29.37 KiB | 578.00 KiB/s, done.\n> Resolving deltas: 100% (94/94), completed with 50 local objects.\n>  From ssh://gitrepo.freebsd.org/ports\n>     80469139f77f..cf8b94761057  main       -> origin/main\n> Successfully rebased and updated refs/heads/main.\n> fatal: Unable to read current working directory: No such file or directory\n>\n>\n> Why does Git have to delete and then create again the directory when it\n> is already there?\n>\n>\n> This isn't a big issue, but it is very odd that git deletes the working\n> directory.\n\nIt was deleted by the rebase operation, because rebase (currently)\nworks by first checking out the target commit onto which it will apply\nall your local patches.  That target didn't have the directory; the\ndirectory was added by your local patches.  So checking out that\ncommit necessarily deletes the directory.  Then rebase applies each of\nyour local patches, one by one, updating the working directory as it\napplies them.  Since your local patches create that directory, it gets\nre-created by this process.\n\nAnd since your current working directory was inside that directory\nthat was deleted, later commands get all confused by the current\nworking directory not existing.\n\nIncidentally, rebase works like this because the default merge\nbackend, recursive, intrinsically works with the working copy and\nupdates it as it goes.  Rebase could theoretically redo each of the\nmerges without updating the working copy, assuming there are no\nconflicts, and then checkout the new target commit at the end.  That'd\nrequire a new merge backend that allowed merging without updating the\nworking copy, though, which was only recently added (see the Git 2.33\nrelease notes).  Rebase has not yet been updated to take advantage of\nthat capability; there's a good chunk of work involved to try to do\nso.  And even when it does, you could still hit this problem if rebase\nhit a conflict on a local patch where the relevant directory did not\nyet exist.\n\n\nHope that helps,\nElijah\n"},{"id":"434010","messageId":"2a7fab29-e7c4-7c23-5932-80c403a37cce@rawbw.com","threadId":"56391","inReplyTo":"CABPp-BFwvDY6-6pQ2MSPzAGafONjTEMNUkLwuRuQCJ_wx2ns2w@mail.gmail.com","subject":"Re: Git re-creates newly added directory when it is pushed","fromName":"Yuri","fromEmail":"yuri@rawbw.com","sentAt":"2021-08-28T05:43:19Z","receivedAt":"2021-08-28T05:43:35Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"On 8/27/21 10:33 PM, Elijah Newren wrote:\n> And I think you left out that you cd'ed into the directory as well\n> before running your `git pull --rebase`.\n\n\nYes, this is how people normally work with this repository. They change \nindividual directories (ports are like sub-projects) and commit them \nwhile staying in them.\n\n\nYuri\n\n"},{"id":"434035","messageId":"xmqqv93n7q1v.fsf@gitster.g","threadId":"56391","inReplyTo":"CABPp-BFwvDY6-6pQ2MSPzAGafONjTEMNUkLwuRuQCJ_wx2ns2w@mail.gmail.com","subject":"Re: Git re-creates newly added directory when it is pushed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-30T00:07:56Z","receivedAt":"2021-08-30T00:08:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren <newren@gmail.com> writes:\n\n>> Why does Git have to delete and then create again the directory when it\n>> is already there?\n>>\n>>\n>> This isn't a big issue, but it is very odd that git deletes the working\n>> directory.\n>\n> It was deleted by the rebase operation, because rebase (currently)\n> works by first checking out the target commit onto which it will apply\n> all your local patches.  That target didn't have the directory; the\n> directory was added by your local patches.  So checking out that\n> commit necessarily deletes the directory.  Then rebase applies each of\n> your local patches, one by one, updating the working directory as it\n> applies them.  Since your local patches create that directory, it gets\n> re-created by this process.\n\nThis is one of the reasons why \"rebase\" (especially \"rebase -i\") may\nwant to insist starting at the top-level of the working tree, like\n\"git bisect\" does.  Because running the command from a subdirectory\nworks most of the time until it doesn't, people tend to complain why\nthey should go up to the top-level before they can run the command.\n\nAnd this is why---it causes end-user confusion.\n\n"},{"id":"434039","messageId":"da2bfcc8-09b2-c909-a316-343ab3108a58@rawbw.com","threadId":"56391","inReplyTo":"xmqqv93n7q1v.fsf@gitster.g","subject":"Re: Git re-creates newly added directory when it is pushed","fromName":"Yuri","fromEmail":"yuri@rawbw.com","sentAt":"2021-08-30T00:14:15Z","receivedAt":"2021-08-30T00:14:23Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"On 8/29/21 5:07 PM, Junio C Hamano wrote:\n> This is one of the reasons why \"rebase\" (especially \"rebase -i\") may\n> want to insist starting at the top-level of the working tree, like\n> \"git bisect\" does.  Because running the command from a subdirectory\n> works most of the time until it doesn't, people tend to complain why\n> they should go up to the top-level before they can run the command.\n>\n> And this is why---it causes end-user confusion.\n\n\nBut there's no confusion here - git doesn't have to delete the directory \nand recreate it, but it does it anyway.\n\nSo this is just a bug that git disturbs users more than it should.\n\n\nYuri\n\n\n"},{"id":"434040","messageId":"xmqqk0k37p1t.fsf@gitster.g","threadId":"56391","inReplyTo":"da2bfcc8-09b2-c909-a316-343ab3108a58@rawbw.com","subject":"Re: Git re-creates newly added directory when it is pushed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-30T00:29:34Z","receivedAt":"2021-08-30T00:29:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yuri <yuri@rawbw.com> writes:\n\n> On 8/29/21 5:07 PM, Junio C Hamano wrote:\n>> This is one of the reasons why \"rebase\" (especially \"rebase -i\") may\n>> want to insist starting at the top-level of the working tree, like\n>> \"git bisect\" does.  Because running the command from a subdirectory\n>> works most of the time until it doesn't, people tend to complain why\n>> they should go up to the top-level before they can run the command.\n>>\n>> And this is why---it causes end-user confusion.\n>\n>\n> But there's no confusion here - git doesn't have to delete the\n> directory and recreate it, but it does it anyway.\n>\n> So this is just a bug that git disturbs users more than it should.\n\nNo, this is an example that users usually can be unaware of the\nreason why it is a bad idea to start from subdirectories.\n\nAs Elijah explained, if a multi-step rebase had to stop and ask help\nfrom the user to resolve conflict _before_ the step that creates the\nuser's current directory, it would leave the user in a confusing\nsituation where the user thinks is in a directory but that directory\ndoes not yet exist in the filesystem.\n"},{"id":"434057","messageId":"677bef35-4d27-748a-1508-2e65707317ee@iee.email","threadId":"56391","inReplyTo":"xmqqk0k37p1t.fsf@gitster.g","subject":"Re: Git re-creates newly added directory when it is pushed","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-08-30T09:27:51Z","receivedAt":"2021-08-30T09:27:54Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 30/08/2021 01:29, Junio C Hamano wrote:\n> Yuri <yuri@rawbw.com> writes:\n>\n>> On 8/29/21 5:07 PM, Junio C Hamano wrote:\n>>> This is one of the reasons why \"rebase\" (especially \"rebase -i\") may\n>>> want to insist starting at the top-level of the working tree, like\n>>> \"git bisect\" does.  Because running the command from a subdirectory\n>>> works most of the time until it doesn't, people tend to complain why\n>>> they should go up to the top-level before they can run the command.\n>>>\n>>> And this is why---it causes end-user confusion.\n>>\n>> But there's no confusion here - git doesn't have to delete the\n>> directory and recreate it, but it does it anyway.\n>>\n>> So this is just a bug that git disturbs users more than it should.\n> No, this is an example that users usually can be unaware of the\n> reason why it is a bad idea to start from subdirectories.\n>\n> As Elijah explained, if a multi-step rebase had to stop and ask help\n> from the user to resolve conflict _before_ the step that creates the\n> user's current directory, it would leave the user in a confusing\n> situation where the user thinks is in a directory but that directory\n> does not yet exist in the filesystem.\nDoes this end up being a documentation issue?\n\ne.g. Users should start at top-level because..\nor Note, if the current directory is removed at some step during the\nrebase then..\n\nOften folk do read the documentation as a lest resort..\n-- \nPhilip\n"},{"id":"434216","messageId":"CABPp-BFE_LB=MYcJ80g=6OjvcXh-SjR_9_ynVdX5i9ruGBqh2Q@mail.gmail.com","threadId":"56391","inReplyTo":"xmqqv93n7q1v.fsf@gitster.g","subject":"Re: Git re-creates newly added directory when it is pushed","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-08-31T02:15:58Z","receivedAt":"2021-08-31T02:16:12Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sun, Aug 29, 2021 at 5:07 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Elijah Newren <newren@gmail.com> writes:\n>\n> >> Why does Git have to delete and then create again the directory when it\n> >> is already there?\n> >>\n> >>\n> >> This isn't a big issue, but it is very odd that git deletes the working\n> >> directory.\n> >\n> > It was deleted by the rebase operation, because rebase (currently)\n> > works by first checking out the target commit onto which it will apply\n> > all your local patches.  That target didn't have the directory; the\n> > directory was added by your local patches.  So checking out that\n> > commit necessarily deletes the directory.  Then rebase applies each of\n> > your local patches, one by one, updating the working directory as it\n> > applies them.  Since your local patches create that directory, it gets\n> > re-created by this process.\n>\n> This is one of the reasons why \"rebase\" (especially \"rebase -i\") may\n> want to insist starting at the top-level of the working tree, like\n> \"git bisect\" does.  Because running the command from a subdirectory\n> works most of the time until it doesn't, people tend to complain why\n> they should go up to the top-level before they can run the command.\n>\n> And this is why---it causes end-user confusion.\n\nMakes sense to me; I'll submit a patch.\n"},{"id":"434230","messageId":"xmqq4kb6z0nr.fsf@gitster.g","threadId":"56391","inReplyTo":"CABPp-BFE_LB=MYcJ80g=6OjvcXh-SjR_9_ynVdX5i9ruGBqh2Q@mail.gmail.com","subject":"Re: Git re-creates newly added directory when it is pushed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-31T04:41:12Z","receivedAt":"2021-08-31T04:41:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren <newren@gmail.com> writes:\n\n>> This is one of the reasons why \"rebase\" (especially \"rebase -i\") may\n>> want to insist starting at the top-level of the working tree, like\n>> \"git bisect\" does.  Because running the command from a subdirectory\n>> works most of the time until it doesn't, people tend to complain why\n>> they should go up to the top-level before they can run the command.\n>>\n>> And this is why---it causes end-user confusion.\n>\n> Makes sense to me; I'll submit a patch.\n\nWell, but not too hastily.\n\nIt is one thing to be firm and resist those who want to loosen \"git\nbisect\" to allow it to start in a subdirectory, in order to keep\nprotecting the innocent who are already protected with the current\nsafeguard from confusion.\n\nIt is entirely a different thing to tighten \"git rebase\"\nretroactively to break those who are used to see the command start\nin a subdirectory.\n\nThe potential confusion that is caused may be the same between\ncommands, but either change can potentially hurt existing users.\n\nI hope your patch would serve as a good discussion starter.  We may\nend up loosening \"git bisect\" to expose our users to possible\nconfusion, the same one that already exists for users of \"git\nrebase\", in the name of consistency, and it might even turn out to\nbe a good change.  Or not.\n\nIn any case, it would be a good opportunity to force people\nthoroughly think things through.\n\nThanks.\n"}]}