{"thread":{"id":"58215","subject":"Dropbox and \"Your local changes to the following files would be overwritten by merge\"","startedAt":"2022-07-23T12:40:36Z","lastAt":"2022-07-26T02:38:45Z","messageCount":6,"participants":["Yuri Kanivetsky","rsbecker@nexbridge.com","brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"459832","messageId":"CAMhVC3acU06uBDAjd5LEiCvuf8=XW_1RYVVt7CdKr-JqB7cRFA@mail.gmail.com","threadId":"58215","inReplyTo":null,"subject":"Dropbox and \"Your local changes to the following files would be overwritten by merge\"","fromName":"Yuri Kanivetsky","fromEmail":"yuri.kanivetsky@gmail.com","sentAt":"2022-07-23T12:40:20Z","receivedAt":"2022-07-23T12:40:36Z","isPatch":false,"sender":{"key":"yuri.kanivetsky@gmail.com","avatar":"https://gravatar.com/avatar/e4d91cf41e555a0c340222a1898c6320f51ad5ab2f9638282cc2412abb450648?d=mp&s=160"},"body":"Hi,\n\nI've started to run into issues with git relatively recently. Let's\ntake the issue I'm experiencing at the moment. I'm trying to rewrite a\nhistory (git rebase -i some-hash, move 4 commits up, rename the last 2\nof them), and it fails to apply the next commit on the todo list after\nthese 4 (I've redacted the message):\n\n[detached HEAD 1888888] name-3\n Date: Mon May 9 22:41:03 2022 +0300\n 1 file changed, 1 insertion(+)\n[detached HEAD 00b5555] name-4\n Date: Sat Jul 23 13:19:42 2022 +0300\n 1 file changed, 1 insertion(+)\nerror: Your local changes to the following files would be overwritten by merge:\n        some paths\nPlease commit your changes or stash them before you merge.\nAborting\nhint: Could not execute the todo command\nhint:\nhint:     pick 8222222222222222222222222222222222222222 name-5\nhint:\nhint: It has been rescheduled; To edit the command before continuing, please\nhint: edit the todo list first:\nhint:\nhint:     git rebase --edit-todo\nhint:     git rebase --continue\nCould not apply 8222222... name-5\n\nThe files it complains about, they're versioned, and they're not\nchanged when it stops. If I copy the repository (cp -r), and repeat\nthe steps, it sometimes succeeds, sometimes not. If I were to split it\ninto smaller steps I believe it would succeed. In other words I got\nthis message occasionally for no apparent reason. Usually it succeeds\nif I simply repeat the steps. Sometimes I need to do it in smaller\nsteps.\n\nFirst I thought it's an issue with vim-fugitive, but I can reproduce\nit with git alone. The other culprits I can think of are magit (I\nbelieve I used it with this repository), vim, and now that I think\nabout it... Dropbox? The repository is in a dropbox directory. I\nunderstand that this is uncommon, but a couple of my repositories are\nin a dropbox directory and I'd like to put the reasons aside. Can you\nsuggest what I can do to find the reason it fails? Do you know what\nexactly triggers this message (the content changed, modification time,\nctime)?\n\nI'm running Alpine Linux and git-2.36.1.\n\nRegards,\nYuri\n"},{"id":"459833","messageId":"01bf01d89e96$699539e0$3cbfada0$@nexbridge.com","threadId":"58215","inReplyTo":"CAMhVC3acU06uBDAjd5LEiCvuf8=XW_1RYVVt7CdKr-JqB7cRFA@mail.gmail.com","subject":"RE: Dropbox and \"Your local changes to the following files would be overwritten by merge\"","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-07-23T13:16:20Z","receivedAt":"2022-07-23T13:20:31Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On July 23, 2022 8:40 AM, Yuri Kanivetsky wrote:\n>I've started to run into issues with git relatively recently. Let's take the issue I'm\n>experiencing at the moment. I'm trying to rewrite a history (git rebase -i some-\n>hash, move 4 commits up, rename the last 2 of them), and it fails to apply the next\n>commit on the todo list after these 4 (I've redacted the message):\n>\n>[detached HEAD 1888888] name-3\n> Date: Mon May 9 22:41:03 2022 +0300\n> 1 file changed, 1 insertion(+)\n>[detached HEAD 00b5555] name-4\n> Date: Sat Jul 23 13:19:42 2022 +0300\n> 1 file changed, 1 insertion(+)\n>error: Your local changes to the following files would be overwritten by merge:\n>        some paths\n>Please commit your changes or stash them before you merge.\n>Aborting\n>hint: Could not execute the todo command\n>hint:\n>hint:     pick 8222222222222222222222222222222222222222 name-5\n>hint:\n>hint: It has been rescheduled; To edit the command before continuing, please\n>hint: edit the todo list first:\n>hint:\n>hint:     git rebase --edit-todo\n>hint:     git rebase --continue\n>Could not apply 8222222... name-5\n>\n>The files it complains about, they're versioned, and they're not changed when it\n>stops. If I copy the repository (cp -r), and repeat the steps, it sometimes succeeds,\n>sometimes not. If I were to split it into smaller steps I believe it would succeed. In\n>other words I got this message occasionally for no apparent reason. Usually it\n>succeeds if I simply repeat the steps. Sometimes I need to do it in smaller steps.\n>\n>First I thought it's an issue with vim-fugitive, but I can reproduce it with git alone.\n>The other culprits I can think of are magit (I believe I used it with this repository),\n>vim, and now that I think about it... Dropbox? The repository is in a dropbox\n>directory. I understand that this is uncommon, but a couple of my repositories are\n>in a dropbox directory and I'd like to put the reasons aside. Can you suggest what I\n>can do to find the reason it fails? Do you know what exactly triggers this message\n>(the content changed, modification time, ctime)?\n>\n>I'm running Alpine Linux and git-2.36.1.\n\nIs DropBox 100% up to date when the operation is run? It uses timestamps to determine whether files changed. Git uses SHA1. So, they each have a different perspective on what is changed. A git status before the operation would tell you what is modified prior to the merge, which could be something DropBox is updating or is pending an update. You could try to do a git stash push prior to the merge and then a git stash pop to isolate whatever DropBox is doing at the time.\n--Randall\n\n"},{"id":"459836","messageId":"YtwH7pOnDgv+MYmh@tapette.crustytoothpaste.net","threadId":"58215","inReplyTo":"CAMhVC3acU06uBDAjd5LEiCvuf8=XW_1RYVVt7CdKr-JqB7cRFA@mail.gmail.com","subject":"Re: Dropbox and \"Your local changes to the following files would be overwritten by merge\"","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-07-23T14:38:38Z","receivedAt":"2022-07-23T14:38:45Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-07-23 at 12:40:20, Yuri Kanivetsky wrote:\n> Hi,\n\nHey,\n\n> First I thought it's an issue with vim-fugitive, but I can reproduce\n> it with git alone. The other culprits I can think of are magit (I\n> believe I used it with this repository), vim, and now that I think\n> about it... Dropbox? The repository is in a dropbox directory. I\n> understand that this is uncommon, but a couple of my repositories are\n> in a dropbox directory and I'd like to put the reasons aside. Can you\n> suggest what I can do to find the reason it fails? Do you know what\n> exactly triggers this message (the content changed, modification time,\n> ctime)?\n\nIt's known that Dropbox and other cloud syncing services can corrupt\nrepositories.  They can cause files to be removed, renamed, or reappear\nafter being deleted, and I suspect that's what's happening here.\n\nI'd definitely suggest moving your repository out of the Dropbox folder\nand seeing if you can reproduce the problem.  That will tell you if\nthat's the problem you're having.\n\nI'd recommend moving the data out of the Dropbox repository regardless,\nsince, as I mentioned, it is known to cause corruption, and you won't\nknow it until it's too late.  You may want to additionally run \"git\nfsck\" to see if that finds any problems other than dangling objects.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"459839","messageId":"xmqqczdvaegs.fsf@gitster.g","threadId":"58215","inReplyTo":"YtwH7pOnDgv+MYmh@tapette.crustytoothpaste.net","subject":"Re: Dropbox and \"Your local changes to the following files would be overwritten by merge\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-23T18:09:07Z","receivedAt":"2022-07-23T18:09:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> It's known that Dropbox and other cloud syncing services can corrupt\n> repositories.  They can cause files to be removed, renamed, or reappear\n> after being deleted, and I suspect that's what's happening here.\n> ...\n> I'd recommend moving the data out of the Dropbox repository regardless,\n> since, as I mentioned, it is known to cause corruption, and you won't\n> know it until it's too late.  You may want to additionally run \"git\n> fsck\" to see if that finds any problems other than dangling objects.\n\nAn anticipated follow-up question is \"but then how do I replicate\nthe repository across my machines? that is the reason why I have it\nin Dropbox in the first place\", and the above is a hard-to-follow\nadvice until it has a good answer.\n\nE.g. after finished working at a site, prepare to take the \"latest\"\nto the next place you will work at in a bundle,\n\n    $ git bundle create 2022-07-23.bndl --all HEAD\n    $ mv 2022-07-23.bndl $my_dropbox_directory/.\n\nand when you get to the next place to work at, you'd \"fetch\" from it\ninto the repository you keep, or you can choose *NOT* to maintain\nany local copy there at all and \"git clone\" from the bundle every\ntime you restart at a different place.\n\n\n\n\n\n\n"},{"id":"459840","messageId":"xmqq7d43adzz.fsf@gitster.g","threadId":"58215","inReplyTo":"xmqqczdvaegs.fsf@gitster.g","subject":"Re: Dropbox and \"Your local changes to the following files would be overwritten by merge\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-23T18:19:12Z","receivedAt":"2022-07-23T18:19:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> E.g. after finished working at a site, prepare to take the \"latest\"\n> to the next place you will work at in a bundle,\n>\n>     $ git bundle create 2022-07-23.bndl --all HEAD\n>     $ mv 2022-07-23.bndl $my_dropbox_directory/.\n>\n> and when you get to the next place to work at, you'd \"fetch\" from it\n> into the repository you keep, or you can choose *NOT* to maintain\n> any local copy there at all and \"git clone\" from the bundle every\n> time you restart at a different place.\n\nA practical real-world solution would certainly involve keeping\nreasonably fresh copies of repositories at each work location, and\n\"git fetch --mirror\" into it from the bundle.  The \"bundle create\"\ncommand would most likely have some bottom revisions to reduce the\nsize of the resulting bundle files, i.e. if you know that all copies\nof repositories you'd work with surely have the version you tagged\n\"v53.8\" a few weeks ago, then the \"bundle create\" command may have\n\"--not v53.8\" at the end.\n\nIn other words, the above is *NOT* meant to be a full solution, but\nmerely to illustrate a possible direction to go in.\n\n\n"},{"id":"459956","messageId":"CAMhVC3aNHpqvG2AQ4yfS34sX67-Z-f3dyyxNRqtdiS_D4z_jbQ@mail.gmail.com","threadId":"58215","inReplyTo":"xmqq7d43adzz.fsf@gitster.g","subject":"Re: Dropbox and \"Your local changes to the following files would be overwritten by merge\"","fromName":"Yuri Kanivetsky","fromEmail":"yuri.kanivetsky@gmail.com","sentAt":"2022-07-26T02:38:29Z","receivedAt":"2022-07-26T02:38:45Z","isPatch":false,"sender":{"key":"yuri.kanivetsky@gmail.com","avatar":"https://gravatar.com/avatar/e4d91cf41e555a0c340222a1898c6320f51ad5ab2f9638282cc2412abb450648?d=mp&s=160"},"body":"Hi,\n\nI'm not sure if it's appropriate with mailing lists, but I'd like to\nrespond to you all with one email. Correct me if I'm doing it wrong.\n\nA couple of points first. The issue happens sometimes. And if my\nmemory serves me right, it might be that at some point it fails, but\nthen I repeat the steps, and it succeeds. Then, there seems to be no\nreason for Dropbox to change the files. That is, it just failed, I'm\nin the middle of a rebase, and Dropbox says that all devices but one\ndid something at least about a day ago. The laptop is up for a while\nnow. And anyway, it's the only machine where I change the repository.\nIf I did change something on other machines, that was long ago.\n\nrsbecker, it fails particularly when Dropbox is up to date. In case it\nmatters, I don't do merges, I do rebases. And if I were to expect\nDropbox to change the versioned files, I wouldn't do the git stash\nthing.\n\nbrian, I'm planning to move the repository out of the dropbox, but\nfirst I'd like to figure out what exactly is happening. Move it out to\nconfirm if it's a Dropbox issue? That wouldn't be a 100% proof. But I\nbet it'd succeed. Anyway, it does seem like a Dropbox issue. And I'm\nplanning to keep an eye on whether it happens only with dropbox\nrepositories (most of my repositories are not in the dropbox).\n\n> You may want to additionally run \"git fsck\" to see if that finds any problems other than dangling objects.\n\nI'm in the middle of an issue, so to say, rebase stopped and `git\nfsck` reports one missing tree, besides dangling objects.\n\nJunio, thanks for the suggestion to use bundles. I didn't know about\nthem, and it looks like an interesting option I should consider. But\nagain, first I'd like to figure out what exactly is happening.\n\nActually, I also tried to build git to add some debug statements, but\ngot stuck with some missing dependencies.\n\nAt the end I'd like to provide details about the latest case. Maybe\nyou can infer something from it. It looks like it tried to apply a\ncommit it already applied a second time. I have a hard time\ninterpreting the current state. It's at commit \"b\", but\n.git/rebase-merge/stopped-sha points to commit \"c\", and\n.git/rebase-merge/done says it applied commit \"b\" twice. Although I'm\nnot sure I'm interpreting it right.\n\nWhat I did:\n\n$ git rebase -i --root # and changed the first pick into edit\n$ git add some-file\n\n$ git rebase --continue\nerror: Your local changes to the following files would be overwritten by merge:\n        some-other-file\nPlease commit your changes or stash them before you merge.\nAborting\nhint: Could not execute the todo command\nhint:\nhint:     pick 0008743 commit c\nhint:\nhint: It has been rescheduled; To edit the command before continuing, please\nhint: edit the todo list first:\nhint:\nhint:     git rebase --edit-todo\nhint:     git rebase --continue\nCould not apply 0008743... commit c\n\n$ git log --all --graph --oneline --decorate\n* 3774372 (HEAD) commit b\n* 2ccb75d commit a\n...\n* 9adb050 commit d\n* 0008743 commit c\n* 3e0cc95 commit b\n* 6df3ef9 commit a\n\n.git/rebase-merge/done:\nedit 6df3ef9 commit a\npick 3e0cc95 commit b\npick 0008743 commit c\npick 3e0cc95 commit b\n\n.git/rebase-merge/git-rebase-todo:\npick 0008743 commit c\npick 9adb050 commit d\n...\n\n.git/rebase-merge/git-rebase-todo.backup:\npick 6df3ef9 commit a\npick 3e0cc95 commit b\npick 0008743 commit c\npick 9adb050 commit d\n...\n\n.git/rebase-merge/message:\ncommit c\n\n.git/rebase-merge/msgnum:\n3\n\n.git/rebase-merge/rewritten-list:\n6df3ef9 2ccb75d\n3e0cc95 3774372\n\n.git/rebase-merge/stopped-sha:\n0008743\n\nRegards,\nYuri\n\nOn Sat, Jul 23, 2022 at 9:19 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n> > E.g. after finished working at a site, prepare to take the \"latest\"\n> > to the next place you will work at in a bundle,\n> >\n> >     $ git bundle create 2022-07-23.bndl --all HEAD\n> >     $ mv 2022-07-23.bndl $my_dropbox_directory/.\n> >\n> > and when you get to the next place to work at, you'd \"fetch\" from it\n> > into the repository you keep, or you can choose *NOT* to maintain\n> > any local copy there at all and \"git clone\" from the bundle every\n> > time you restart at a different place.\n>\n> A practical real-world solution would certainly involve keeping\n> reasonably fresh copies of repositories at each work location, and\n> \"git fetch --mirror\" into it from the bundle.  The \"bundle create\"\n> command would most likely have some bottom revisions to reduce the\n> size of the resulting bundle files, i.e. if you know that all copies\n> of repositories you'd work with surely have the version you tagged\n> \"v53.8\" a few weeks ago, then the \"bundle create\" command may have\n> \"--not v53.8\" at the end.\n>\n> In other words, the above is *NOT* meant to be a full solution, but\n> merely to illustrate a possible direction to go in.\n>\n>\n"}]}