{"thread":{"id":"54810","subject":"Why does \"git pull --rebase\" require a clean git directory?","startedAt":"2020-12-10T23:06:48Z","lastAt":"2020-12-12T11:30:40Z","messageCount":5,"participants":["Shupak, Vitaly","brian m. carlson","Phillip Susi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"412021","messageId":"ea1e654cec62411884e2c260524fb05a@deshaw.com","threadId":"54810","inReplyTo":null,"subject":"Why does \"git pull --rebase\" require a clean git directory?","fromName":"Shupak, Vitaly","fromEmail":"vitaly.shupak@deshaw.com","sentAt":"2020-12-10T22:15:11Z","receivedAt":"2020-12-10T23:06:48Z","isPatch":false,"sender":{"key":"vitaly.shupak@deshaw.com","avatar":null},"body":"Hi,\n\n\"git pull --rebase\" requires having NO uncommitted changes, even if the locally modified files haven't been updated upstream, or even if there are no changes to upstream at all. I know I could use --autostash, but that's inefficient and may be undesirable if it would create a conflict.\n\nWould it be possible to change the behavior of \"git pull --rebase\" so that it only fails if the locally modified files conflict with the files modified upstream (similar to the default git pull behavior without --rebase)?\n\nThanks,\nVitaly\n\n"},{"id":"412043","messageId":"X9LqnolNcWZvA7Bm@camp.crustytoothpaste.net","threadId":"54810","inReplyTo":"ea1e654cec62411884e2c260524fb05a@deshaw.com","subject":"Re: Why does \"git pull --rebase\" require a clean git directory?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-12-11T03:42:22Z","receivedAt":"2020-12-11T03:44:55Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-12-10 at 22:15:11, Shupak, Vitaly wrote:\n> Hi,\n> \n> \"git pull --rebase\" requires having NO uncommitted changes, even if\n> the locally modified files haven't been updated upstream, or even if\n> there are no changes to upstream at all. I know I could use\n> --autostash, but that's inefficient and may be undesirable if it would\n> create a conflict.\n> \n> Would it be possible to change the behavior of \"git pull --rebase\" so\n> that it only fails if the locally modified files conflict with the\n> files modified upstream (similar to the default git pull behavior\n> without --rebase)?\n\nI suspect the reason for the difference is in how the two pieces of code\nwork. A merge in general can work in a dirty tree whereas a rebase\ncannot. That, in turn, is because the merge code merges two files\ninternally and then writes them out to the working tree, whereas the\nrebase code, at least in some cases, doesn't contain the same\nprecautions not to modify the working tree.\n\nMoreover, a merge is a single operation, so it's safe to operate on a\ncommit and then give up. A rebase consists of multiple operations, so\nwe'd have to evaluate each operation and synthesize it, internally\nperforming the merge (or apply) that's a part of it, in order to\ndetermine if it would conflict. Otherwise, we'd have to just try it and\nsomehow abort cleanly in the middle without otherwise dirtying the\nworking tree. Right now, that abort step involves a reset --hard, which\nis going to blow away your data.\n\nSo is it possible to do? Sure. Is it easy? Not especially with the\ncurrent code. So certainly it could be done if it were important to\nsomeone, but it will likely be a good bit of work.\n\nSorry this wasn't the news you were hoping for. I'd love to have some\neasy solution that I could offer to send in a patch for this weekend to\nsolve this, but unfortunately it's not that easy.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"412083","messageId":"87a6uk78rl.fsf@vps.thesusis.net","threadId":"54810","inReplyTo":"ea1e654cec62411884e2c260524fb05a@deshaw.com","subject":"Re: Why does \"git pull --rebase\" require a clean git directory?","fromName":"Phillip Susi","fromEmail":"phill@thesusis.net","sentAt":"2020-12-11T13:46:12Z","receivedAt":"2020-12-11T13:50:32Z","isPatch":false,"sender":{"key":"phill@thesusis.net","avatar":null},"body":"\nShupak, Vitaly writes:\n\n> \"git pull --rebase\" requires having NO uncommitted changes, even if\n> the locally modified files haven't been updated upstream, or even if\n> there are no changes to upstream at all. I know I could use\n\nIt isn't just about whether upstream has changed those same files, but\nalso would fail if any of your commits have.\n\n> --autostash, but that's inefficient and may be undesirable if it would\n> create a conflict.\n\nIf that creates a conflict, then the pull would definitely fail if it\nhad been attempted.\n"},{"id":"412097","messageId":"f5b5b94830ca45b69440c0ebc1de5e69@deshaw.com","threadId":"54810","inReplyTo":"X9LqnolNcWZvA7Bm@camp.crustytoothpaste.net","subject":"RE: Why does \"git pull --rebase\" require a clean git directory?","fromName":"Shupak, Vitaly","fromEmail":"vitaly.shupak@deshaw.com","sentAt":"2020-12-11T21:23:23Z","receivedAt":"2020-12-11T22:31:20Z","isPatch":false,"sender":{"key":"vitaly.shupak@deshaw.com","avatar":null},"body":"Thanks for the explanation. It seems like some optimizations may still be possible. For example, if the pull could be done with a fast-forward merge, then you don't need to rebase at all. This could be an option like pull.rebase=noffonly.\n\n-----Original Message-----\nFrom: brian m. carlson \nSent: Thursday, December 10, 2020 10:42 PM\nTo: Shupak, Vitaly \nCc: git@vger.kernel.org\nSubject: Re: Why does \"git pull --rebase\" require a clean git directory?\n\nOn 2020-12-10 at 22:15:11, Shupak, Vitaly wrote:\n> Hi,\n> \n> \"git pull --rebase\" requires having NO uncommitted changes, even if \n> the locally modified files haven't been updated upstream, or even if \n> there are no changes to upstream at all. I know I could use \n> --autostash, but that's inefficient and may be undesirable if it would \n> create a conflict.\n> \n> Would it be possible to change the behavior of \"git pull --rebase\" so \n> that it only fails if the locally modified files conflict with the \n> files modified upstream (similar to the default git pull behavior \n> without --rebase)?\n\nI suspect the reason for the difference is in how the two pieces of code work. A merge in general can work in a dirty tree whereas a rebase cannot. That, in turn, is because the merge code merges two files internally and then writes them out to the working tree, whereas the rebase code, at least in some cases, doesn't contain the same precautions not to modify the working tree.\n\nMoreover, a merge is a single operation, so it's safe to operate on a commit and then give up. A rebase consists of multiple operations, so we'd have to evaluate each operation and synthesize it, internally performing the merge (or apply) that's a part of it, in order to determine if it would conflict. Otherwise, we'd have to just try it and somehow abort cleanly in the middle without otherwise dirtying the working tree. Right now, that abort step involves a reset --hard, which is going to blow away your data.\n\nSo is it possible to do? Sure. Is it easy? Not especially with the current code. So certainly it could be done if it were important to someone, but it will likely be a good bit of work.\n\nSorry this wasn't the news you were hoping for. I'd love to have some easy solution that I could offer to send in a patch for this weekend to solve this, but unfortunately it's not that easy.\n--\nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"412112","messageId":"X9SpmGKUVgrSBy9j@camp.crustytoothpaste.net","threadId":"54810","inReplyTo":"f5b5b94830ca45b69440c0ebc1de5e69@deshaw.com","subject":"Re: Why does \"git pull --rebase\" require a clean git directory?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-12-12T11:29:28Z","receivedAt":"2020-12-12T11:30:40Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-12-11 at 21:23:23, Shupak, Vitaly wrote:\n> Thanks for the explanation. It seems like some optimizations may still\n> be possible. For example, if the pull could be done with a\n> fast-forward merge, then you don't need to rebase at all. This could\n> be an option like pull.rebase=noffonly.\n\nYeah, I agree that if our operation is a fast-forward, that could be\ndone in a pretty straightforward way. It's still a little tricky\nbecause of how the current code works (the fast-forward logic is in the\nsequencer, which gets called after the check), but it's something that\nwe could add more easily.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"}]}