* 2.43+ git checkout --theirs on stash error - no alternative?
@ 2024-10-27 22:16 Devste Devste
2024-10-27 22:31 ` Devste Devste
0 siblings, 1 reply; 6+ messages in thread
From: Devste Devste @ 2024-10-27 22:16 UTC (permalink / raw)
To: git
What did you do before the bug happened? (Steps to reproduce your issue)
git checkout 'stash@{0}' --theirs -- "some-file.txt"
What did you expect to happen? (Expected behavior)
Checking out the file exactly as it is in the stash with any conflicts
resolved using the stash's data
What happened instead? (Actual behavior)
fatal: '--merge', '--ours', or '--theirs' cannot be used when checking
out of a tree
What's different between what you expected and what actually happened?
Error and unresolved conflicts
Anything else you want to add:
This behavior was changed in 2.43
https://www.spinics.net/lists/git/msg463600.html
However, I think this change is wrong. Since using --theirs still
makes sense, if you want to restore a file to the exact state it was
in the stash.
While the change probably had in mind that this should be used: git
cherry-pick --no-commit --mainline 1 --strategy-option=theirs
'stash@{0}'
This leads to different results than git checkout --theirs, since it
tries to resolve the conflicts and is not correctly using "theirs" to
automatically resolve them
How can the pre 2.43 behavior be achieved?
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.43.5
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.14.0-162.23.1.el9_1.x86_64 #1 SMP PREEMPT_DYNAMIC Tue
Apr 11 19:09:37 UTC 2023 x86_64
compiler info: gnuc: 11.4
libc info: glibc: 2.34
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: 2.43+ git checkout --theirs on stash error - no alternative?
2024-10-27 22:16 2.43+ git checkout --theirs on stash error - no alternative? Devste Devste
@ 2024-10-27 22:31 ` Devste Devste
2024-10-27 23:38 ` Taylor Blau
0 siblings, 1 reply; 6+ messages in thread
From: Devste Devste @ 2024-10-27 22:31 UTC (permalink / raw)
To: git
Turns out the previous behavior can be achieved with
git restore --source='stash@{0}' -- "some-file.txt"
On Sun, 27 Oct 2024 at 23:16, Devste Devste <devstemail@gmail.com> wrote:
>
> What did you do before the bug happened? (Steps to reproduce your issue)
> git checkout 'stash@{0}' --theirs -- "some-file.txt"
>
> What did you expect to happen? (Expected behavior)
> Checking out the file exactly as it is in the stash with any conflicts
> resolved using the stash's data
>
> What happened instead? (Actual behavior)
> fatal: '--merge', '--ours', or '--theirs' cannot be used when checking
> out of a tree
>
> What's different between what you expected and what actually happened?
> Error and unresolved conflicts
>
> Anything else you want to add:
> This behavior was changed in 2.43
> https://www.spinics.net/lists/git/msg463600.html
> However, I think this change is wrong. Since using --theirs still
> makes sense, if you want to restore a file to the exact state it was
> in the stash.
> While the change probably had in mind that this should be used: git
> cherry-pick --no-commit --mainline 1 --strategy-option=theirs
> 'stash@{0}'
> This leads to different results than git checkout --theirs, since it
> tries to resolve the conflicts and is not correctly using "theirs" to
> automatically resolve them
> How can the pre 2.43 behavior be achieved?
>
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
>
>
> [System Info]
> git version:
> git version 2.43.5
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Linux 5.14.0-162.23.1.el9_1.x86_64 #1 SMP PREEMPT_DYNAMIC Tue
> Apr 11 19:09:37 UTC 2023 x86_64
> compiler info: gnuc: 11.4
> libc info: glibc: 2.34
> $SHELL (typically, interactive shell): /bin/bash
>
>
> [Enabled Hooks]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: 2.43+ git checkout --theirs on stash error - no alternative?
2024-10-27 22:31 ` Devste Devste
@ 2024-10-27 23:38 ` Taylor Blau
2024-11-04 10:09 ` Devste Devste
0 siblings, 1 reply; 6+ messages in thread
From: Taylor Blau @ 2024-10-27 23:38 UTC (permalink / raw)
To: Devste Devste; +Cc: git, Junio C Hamano
On Sun, Oct 27, 2024 at 11:31:05PM +0100, Devste Devste wrote:
> Turns out the previous behavior can be achieved with
> git restore --source='stash@{0}' -- "some-file.txt"
Hmm. What you wrote above here makes sense, but I agree with the
original change from Junio (CC'd) that using `--theirs` does not make
sense when the source is a tree-ish and not the index directly.
This is different, though, since here you are just trying to check out
the contents of some-file.txt at stash@{0}, without `--theirs`. What did
you mean in the previous example, and why was `--theirs` necessary in
the call there?
Thanks,
Taylor
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: 2.43+ git checkout --theirs on stash error - no alternative?
2024-10-27 23:38 ` Taylor Blau
@ 2024-11-04 10:09 ` Devste Devste
2024-11-04 10:17 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Devste Devste @ 2024-11-04 10:09 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, Junio C Hamano
"--theirs" was necessary since I want the file exactly as it is in the
stash - any conflicts from applying the file from stash should be
automatically resolved using the hunk from the stash
On Mon, 28 Oct 2024 at 00:38, Taylor Blau <me@ttaylorr.com> wrote:
>
> On Sun, Oct 27, 2024 at 11:31:05PM +0100, Devste Devste wrote:
> > Turns out the previous behavior can be achieved with
> > git restore --source='stash@{0}' -- "some-file.txt"
>
> Hmm. What you wrote above here makes sense, but I agree with the
> original change from Junio (CC'd) that using `--theirs` does not make
> sense when the source is a tree-ish and not the index directly.
>
> This is different, though, since here you are just trying to check out
> the contents of some-file.txt at stash@{0}, without `--theirs`. What did
> you mean in the previous example, and why was `--theirs` necessary in
> the call there?
>
> Thanks,
> Taylor
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: 2.43+ git checkout --theirs on stash error - no alternative?
2024-11-04 10:09 ` Devste Devste
@ 2024-11-04 10:17 ` Junio C Hamano
2024-11-06 10:16 ` Devste Devste
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2024-11-04 10:17 UTC (permalink / raw)
To: Devste Devste; +Cc: Taylor Blau, git
Devste Devste <devstemail@gmail.com> writes:
> On Mon, 28 Oct 2024 at 00:38, Taylor Blau <me@ttaylorr.com> wrote:
>>
>> On Sun, Oct 27, 2024 at 11:31:05PM +0100, Devste Devste wrote:
>> > Turns out the previous behavior can be achieved with
>> > git restore --source='stash@{0}' -- "some-file.txt"
>>
>> Hmm. What you wrote above here makes sense, but I agree with the
>> original change from Junio (CC'd) that using `--theirs` does not make
>> sense when the source is a tree-ish and not the index directly.
>>
>> This is different, though, since here you are just trying to check out
>> the contents of some-file.txt at stash@{0}, without `--theirs`. What did
>> you mean in the previous example, and why was `--theirs` necessary in
>> the call there?
> "--theirs" was necessary since I want the file exactly as it is in the
> stash - any conflicts from applying the file from stash should be
> automatically resolved using the hunk from the stash
But "--theirs" is to take their version unconditionally, isn't it?
There is no "if conflicted take theirs", or "take theirs only in
conflicted parts, but otherwise take a natural merge result". At
least, I do not recall writing the code to behave that way.
So I am not sure if you are getting what you _think_ you are gettin
by passing "--theirs".
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: 2.43+ git checkout --theirs on stash error - no alternative?
2024-11-04 10:17 ` Junio C Hamano
@ 2024-11-06 10:16 ` Devste Devste
0 siblings, 0 replies; 6+ messages in thread
From: Devste Devste @ 2024-11-06 10:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Taylor Blau, git
Afaik it means any conflicts should be resolved using --theirs
strategy (like in git merge-file --theirs) and if I remember
correctly, this is also how it behaved when testing it.
On Mon, 4 Nov 2024 at 11:17, Junio C Hamano <gitster@pobox.com> wrote:
>
> Devste Devste <devstemail@gmail.com> writes:
>
> > On Mon, 28 Oct 2024 at 00:38, Taylor Blau <me@ttaylorr.com> wrote:
> >>
> >> On Sun, Oct 27, 2024 at 11:31:05PM +0100, Devste Devste wrote:
> >> > Turns out the previous behavior can be achieved with
> >> > git restore --source='stash@{0}' -- "some-file.txt"
> >>
> >> Hmm. What you wrote above here makes sense, but I agree with the
> >> original change from Junio (CC'd) that using `--theirs` does not make
> >> sense when the source is a tree-ish and not the index directly.
> >>
> >> This is different, though, since here you are just trying to check out
> >> the contents of some-file.txt at stash@{0}, without `--theirs`. What did
> >> you mean in the previous example, and why was `--theirs` necessary in
> >> the call there?
>
> > "--theirs" was necessary since I want the file exactly as it is in the
> > stash - any conflicts from applying the file from stash should be
> > automatically resolved using the hunk from the stash
>
> But "--theirs" is to take their version unconditionally, isn't it?
> There is no "if conflicted take theirs", or "take theirs only in
> conflicted parts, but otherwise take a natural merge result". At
> least, I do not recall writing the code to behave that way.
>
> So I am not sure if you are getting what you _think_ you are gettin
> by passing "--theirs".
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-11-06 10:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-27 22:16 2.43+ git checkout --theirs on stash error - no alternative? Devste Devste
2024-10-27 22:31 ` Devste Devste
2024-10-27 23:38 ` Taylor Blau
2024-11-04 10:09 ` Devste Devste
2024-11-04 10:17 ` Junio C Hamano
2024-11-06 10:16 ` Devste Devste
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).