{"thread":{"id":"62414","subject":"2.43+ git checkout --theirs on stash error - no alternative?","startedAt":"2024-10-27T22:16:53Z","lastAt":"2024-11-06T10:16:20Z","messageCount":6,"participants":["Devste Devste","Taylor Blau","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"506166","messageId":"CANM0SV0KKd+WN4MQ1_8fEvFyD4tYY3qAUsUh9Njcy1xo1hNSBw@mail.gmail.com","threadId":"62414","inReplyTo":null,"subject":"2.43+ git checkout --theirs on stash error - no alternative?","fromName":"Devste Devste","fromEmail":"devstemail@gmail.com","sentAt":"2024-10-27T22:16:39Z","receivedAt":"2024-10-27T22:16:53Z","isPatch":false,"sender":{"key":"devstemail@gmail.com","avatar":null},"body":"What did you do before the bug happened? (Steps to reproduce your issue)\ngit checkout 'stash@{0}' --theirs -- \"some-file.txt\"\n\nWhat did you expect to happen? (Expected behavior)\nChecking out the file exactly as it is in the stash with any conflicts\nresolved using the stash's data\n\nWhat happened instead? (Actual behavior)\nfatal: '--merge', '--ours', or '--theirs' cannot be used when checking\nout of a tree\n\nWhat's different between what you expected and what actually happened?\nError and unresolved conflicts\n\nAnything else you want to add:\nThis behavior was changed in 2.43\nhttps://www.spinics.net/lists/git/msg463600.html\nHowever, I think this change is wrong. Since using --theirs still\nmakes sense, if you want to restore a file to the exact state it was\nin the stash.\nWhile the change probably had in mind that this should be used: git\ncherry-pick --no-commit --mainline 1 --strategy-option=theirs\n'stash@{0}'\nThis leads to different results than git checkout --theirs, since it\ntries to resolve the conflicts and is not correctly using \"theirs\" to\nautomatically resolve them\nHow can the pre 2.43 behavior be achieved?\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.43.5\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 5.14.0-162.23.1.el9_1.x86_64 #1 SMP PREEMPT_DYNAMIC Tue\nApr 11 19:09:37 UTC 2023 x86_64\ncompiler info: gnuc: 11.4\nlibc info: glibc: 2.34\n$SHELL (typically, interactive shell): /bin/bash\n\n\n[Enabled Hooks]\n"},{"id":"506167","messageId":"CANM0SV0Muk8KT6Mv=14ui07c6OzaNDDQwg2bUVRb8JyJWTyHnQ@mail.gmail.com","threadId":"62414","inReplyTo":"CANM0SV0KKd+WN4MQ1_8fEvFyD4tYY3qAUsUh9Njcy1xo1hNSBw@mail.gmail.com","subject":"Re: 2.43+ git checkout --theirs on stash error - no alternative?","fromName":"Devste Devste","fromEmail":"devstemail@gmail.com","sentAt":"2024-10-27T22:31:05Z","receivedAt":"2024-10-27T22:31:19Z","isPatch":false,"sender":{"key":"devstemail@gmail.com","avatar":null},"body":"Turns out the previous behavior can be achieved with\ngit restore --source='stash@{0}' -- \"some-file.txt\"\n\nOn Sun, 27 Oct 2024 at 23:16, Devste Devste <devstemail@gmail.com> wrote:\n>\n> What did you do before the bug happened? (Steps to reproduce your issue)\n> git checkout 'stash@{0}' --theirs -- \"some-file.txt\"\n>\n> What did you expect to happen? (Expected behavior)\n> Checking out the file exactly as it is in the stash with any conflicts\n> resolved using the stash's data\n>\n> What happened instead? (Actual behavior)\n> fatal: '--merge', '--ours', or '--theirs' cannot be used when checking\n> out of a tree\n>\n> What's different between what you expected and what actually happened?\n> Error and unresolved conflicts\n>\n> Anything else you want to add:\n> This behavior was changed in 2.43\n> https://www.spinics.net/lists/git/msg463600.html\n> However, I think this change is wrong. Since using --theirs still\n> makes sense, if you want to restore a file to the exact state it was\n> in the stash.\n> While the change probably had in mind that this should be used: git\n> cherry-pick --no-commit --mainline 1 --strategy-option=theirs\n> 'stash@{0}'\n> This leads to different results than git checkout --theirs, since it\n> tries to resolve the conflicts and is not correctly using \"theirs\" to\n> automatically resolve them\n> How can the pre 2.43 behavior be achieved?\n>\n> Please review the rest of the bug report below.\n> You can delete any lines you don't wish to share.\n>\n>\n> [System Info]\n> git version:\n> git version 2.43.5\n> cpu: x86_64\n> no commit associated with this build\n> sizeof-long: 8\n> sizeof-size_t: 8\n> shell-path: /bin/sh\n> uname: Linux 5.14.0-162.23.1.el9_1.x86_64 #1 SMP PREEMPT_DYNAMIC Tue\n> Apr 11 19:09:37 UTC 2023 x86_64\n> compiler info: gnuc: 11.4\n> libc info: glibc: 2.34\n> $SHELL (typically, interactive shell): /bin/bash\n>\n>\n> [Enabled Hooks]\n"},{"id":"506170","messageId":"Zx7O3VsZX2B9d9qN@nand.local","threadId":"62414","inReplyTo":"CANM0SV0Muk8KT6Mv=14ui07c6OzaNDDQwg2bUVRb8JyJWTyHnQ@mail.gmail.com","subject":"Re: 2.43+ git checkout --theirs on stash error - no alternative?","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-10-27T23:38:05Z","receivedAt":"2024-10-27T23:38:09Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Sun, Oct 27, 2024 at 11:31:05PM +0100, Devste Devste wrote:\n> Turns out the previous behavior can be achieved with\n> git restore --source='stash@{0}' -- \"some-file.txt\"\n\nHmm. What you wrote above here makes sense, but I agree with the\noriginal change from Junio (CC'd) that using `--theirs` does not make\nsense when the source is a tree-ish and not the index directly.\n\nThis is different, though, since here you are just trying to check out\nthe contents of some-file.txt at stash@{0}, without `--theirs`. What did\nyou mean in the previous example, and why was `--theirs` necessary in\nthe call there?\n\nThanks,\nTaylor\n"},{"id":"506508","messageId":"CANM0SV3vNBwoNw08AevHE-3cOjUTG4AGVJdpwfKCr=CX5DSW8w@mail.gmail.com","threadId":"62414","inReplyTo":"Zx7O3VsZX2B9d9qN@nand.local","subject":"Re: 2.43+ git checkout --theirs on stash error - no alternative?","fromName":"Devste Devste","fromEmail":"devstemail@gmail.com","sentAt":"2024-11-04T10:09:40Z","receivedAt":"2024-11-04T10:09:54Z","isPatch":false,"sender":{"key":"devstemail@gmail.com","avatar":null},"body":"\"--theirs\" was necessary since I want the file exactly as it is in the\nstash - any conflicts from applying the file from stash should be\nautomatically resolved using the hunk from the stash\n\nOn Mon, 28 Oct 2024 at 00:38, Taylor Blau <me@ttaylorr.com> wrote:\n>\n> On Sun, Oct 27, 2024 at 11:31:05PM +0100, Devste Devste wrote:\n> > Turns out the previous behavior can be achieved with\n> > git restore --source='stash@{0}' -- \"some-file.txt\"\n>\n> Hmm. What you wrote above here makes sense, but I agree with the\n> original change from Junio (CC'd) that using `--theirs` does not make\n> sense when the source is a tree-ish and not the index directly.\n>\n> This is different, though, since here you are just trying to check out\n> the contents of some-file.txt at stash@{0}, without `--theirs`. What did\n> you mean in the previous example, and why was `--theirs` necessary in\n> the call there?\n>\n> Thanks,\n> Taylor\n"},{"id":"506509","messageId":"xmqqmsifwbes.fsf@gitster.g","threadId":"62414","inReplyTo":"CANM0SV3vNBwoNw08AevHE-3cOjUTG4AGVJdpwfKCr=CX5DSW8w@mail.gmail.com","subject":"Re: 2.43+ git checkout --theirs on stash error - no alternative?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-11-04T10:17:31Z","receivedAt":"2024-11-04T10:17:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Devste Devste <devstemail@gmail.com> writes:\n\n> On Mon, 28 Oct 2024 at 00:38, Taylor Blau <me@ttaylorr.com> wrote:\n>>\n>> On Sun, Oct 27, 2024 at 11:31:05PM +0100, Devste Devste wrote:\n>> > Turns out the previous behavior can be achieved with\n>> > git restore --source='stash@{0}' -- \"some-file.txt\"\n>>\n>> Hmm. What you wrote above here makes sense, but I agree with the\n>> original change from Junio (CC'd) that using `--theirs` does not make\n>> sense when the source is a tree-ish and not the index directly.\n>>\n>> This is different, though, since here you are just trying to check out\n>> the contents of some-file.txt at stash@{0}, without `--theirs`. What did\n>> you mean in the previous example, and why was `--theirs` necessary in\n>> the call there?\n\n> \"--theirs\" was necessary since I want the file exactly as it is in the\n> stash - any conflicts from applying the file from stash should be\n> automatically resolved using the hunk from the stash\n\nBut \"--theirs\" is to take their version unconditionally, isn't it?\nThere is no \"if conflicted take theirs\", or \"take theirs only in\nconflicted parts, but otherwise take a natural merge result\".  At\nleast, I do not recall writing the code to behave that way.\n\nSo I am not sure if you are getting what you _think_ you are gettin\nby passing \"--theirs\".\n\n"},{"id":"506706","messageId":"CANM0SV3iF5str0r=BKUOV=wu+Ljn-hR2xcs3zqxfXWrhUigOJQ@mail.gmail.com","threadId":"62414","inReplyTo":"xmqqmsifwbes.fsf@gitster.g","subject":"Re: 2.43+ git checkout --theirs on stash error - no alternative?","fromName":"Devste Devste","fromEmail":"devstemail@gmail.com","sentAt":"2024-11-06T10:16:07Z","receivedAt":"2024-11-06T10:16:20Z","isPatch":false,"sender":{"key":"devstemail@gmail.com","avatar":null},"body":"Afaik it means any conflicts should be resolved using --theirs\nstrategy (like in git merge-file --theirs) and if I remember\ncorrectly, this is also how it behaved when testing it.\n\nOn Mon, 4 Nov 2024 at 11:17, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Devste Devste <devstemail@gmail.com> writes:\n>\n> > On Mon, 28 Oct 2024 at 00:38, Taylor Blau <me@ttaylorr.com> wrote:\n> >>\n> >> On Sun, Oct 27, 2024 at 11:31:05PM +0100, Devste Devste wrote:\n> >> > Turns out the previous behavior can be achieved with\n> >> > git restore --source='stash@{0}' -- \"some-file.txt\"\n> >>\n> >> Hmm. What you wrote above here makes sense, but I agree with the\n> >> original change from Junio (CC'd) that using `--theirs` does not make\n> >> sense when the source is a tree-ish and not the index directly.\n> >>\n> >> This is different, though, since here you are just trying to check out\n> >> the contents of some-file.txt at stash@{0}, without `--theirs`. What did\n> >> you mean in the previous example, and why was `--theirs` necessary in\n> >> the call there?\n>\n> > \"--theirs\" was necessary since I want the file exactly as it is in the\n> > stash - any conflicts from applying the file from stash should be\n> > automatically resolved using the hunk from the stash\n>\n> But \"--theirs\" is to take their version unconditionally, isn't it?\n> There is no \"if conflicted take theirs\", or \"take theirs only in\n> conflicted parts, but otherwise take a natural merge result\".  At\n> least, I do not recall writing the code to behave that way.\n>\n> So I am not sure if you are getting what you _think_ you are gettin\n> by passing \"--theirs\".\n>\n"}]}