threads / discuss / 58958

Strange "git stash pop" conflict (one chunk out of many)

Subject: Strange "git stash pop" conflict (one chunk out of many)

## tl;dr

6 messages between Dec 15, 2022 and Dec 19, 2022.

replies: 5people: 3as markdown or json

Ulrich Windl· Dec 15, 2022, 11:38 UTC · lore
Hi!

This is for a somewhat older git-2.26.2: I had added interactively some changes using edit of a few junks (I tried to structure my big hacking into logical junks when committing). To test whether the partial commit would be consistent, I did a "git stash -k" before committing, and after committing I did a "git stash pop" to continue hacking.

Unfortunately I had a "Merge conflict". Looking at it, it is rather "interesting", however (meaning: I don't understand it). Here is how the conflict looks (to me both variants seem identical):

        # pre-allocate translations and accesskeys
<<<<<<< Updated upstream
        foreach my $attr (LD_SEARCH_ATTR) {
            $attr{$attr} = [translate_attr($attr), undef];
            $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
        }
        foreach my $attr (LD_SEARCH_ATTR) {
=======
        foreach my $attr (LD_SEARCH_ATTR) {
            $attr{$attr} = [translate_attr($attr), undef];
            $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
        }
        foreach my $attr (LD_SEARCH_ATTR) {
>>>>>>> Stashed changes
            @n = (P_P_SRCH_ATTR . $attr, @{$attr{$attr}});
(the other conflict junks look reasonable)

Regards, Ulrich

Bagas Sanjaya· Dec 17, 2022, 01:58 UTC · re: Ulrich Windl · lore

Re: Strange "git stash pop" conflict (one chunk out of many)

On 12/15/22 18:38, Ulrich Windl wrote:
Show 18 quoted lines
> Here is how the conflict looks (to me both variants seem identical):
> 
>         # pre-allocate translations and accesskeys
> <<<<<<< Updated upstream
>         foreach my $attr (LD_SEARCH_ATTR) {
>             $attr{$attr} = [translate_attr($attr), undef];
>             $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
>         }
>         foreach my $attr (LD_SEARCH_ATTR) {
> =======
>         foreach my $attr (LD_SEARCH_ATTR) {
>             $attr{$attr} = [translate_attr($attr), undef];
>             $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
>         }
>         foreach my $attr (LD_SEARCH_ATTR) {
>>>>>>>> Stashed changes
>             @n = (P_P_SRCH_ATTR . $attr, @{$attr{$attr}});
> 
Both sides are identical? You can freely choose either side...
-- 
An old man doll... just what I always wanted! - Clara
Phillip Wood· Dec 17, 2022, 10:45 UTC · re: Bagas Sanjaya · lore

Re: Strange "git stash pop" conflict (one chunk out of many)

On 17/12/2022 01:58, Bagas Sanjaya wrote:
Show 21 quoted lines
> On 12/15/22 18:38, Ulrich Windl wrote:
>> Here is how the conflict looks (to me both variants seem identical):
>>
>>          # pre-allocate translations and accesskeys
>> <<<<<<< Updated upstream
>>          foreach my $attr (LD_SEARCH_ATTR) {
>>              $attr{$attr} = [translate_attr($attr), undef];
>>              $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
>>          }
>>          foreach my $attr (LD_SEARCH_ATTR) {
>> =======
>>          foreach my $attr (LD_SEARCH_ATTR) {
>>              $attr{$attr} = [translate_attr($attr), undef];
>>              $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
>>          }
>>          foreach my $attr (LD_SEARCH_ATTR) {
>>>>>>>>> Stashed changes
>>              @n = (P_P_SRCH_ATTR . $attr, @{$attr{$attr}});
>>
> 
> Both sides are identical? You can freely choose either side...

But if both sides are identical then there should not be a conflict - that is what Ulrich is asking about I think.

Best Wishes
Phillip
Ulrich Windl· Dec 19, 2022, 07:16 UTC · re: Bagas Sanjaya · lore

Antw: [EXT] Re: Strange "git stash pop" conflict (one chunk out of many)

>>> Bagas Sanjaya <bagasdotme@gmail.com> schrieb am 17.12.2022 um 02:58 in
Nachricht <ced6bacc-3d77-4d24-33f3-a93d2ae7a131@gmail.com>:
Show 21 quoted lines
> On 12/15/22 18:38, Ulrich Windl wrote:
>> Here is how the conflict looks (to me both variants seem identical):
>> 
>>         # pre-allocate translations and accesskeys
>> <<<<<<< Updated upstream
>>         foreach my $attr (LD_SEARCH_ATTR) {
>>             $attr{$attr} = [translate_attr($attr), undef];
>>             $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
>>         }
>>         foreach my $attr (LD_SEARCH_ATTR) {
>> =======
>>         foreach my $attr (LD_SEARCH_ATTR) {
>>             $attr{$attr} = [translate_attr($attr), undef];
>>             $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
>>         }
>>         foreach my $attr (LD_SEARCH_ATTR) {
>>>>>>>>> Stashed changes
>>             @n = (P_P_SRCH_ATTR . $attr, @{$attr{$attr}});
>> 
> 
> Both sides are identical? You can freely choose either side...

Yes, but why do I have to handle this obvious non-conflict? Couldn't "stash" handle that, too? In fact that was the only conflict I had.

> 
> -- 
> An old man doll... just what I always wanted! - Clara
Phillip Wood· Dec 17, 2022, 10:44 UTC · re: Ulrich Windl · lore

Re: Strange "git stash pop" conflict (one chunk out of many)

Hi Ulrich
On 15/12/2022 11:38, Ulrich Windl wrote:
Show 8 quoted lines
> Hi!
> 
> This is for a somewhat older git-2.26.2:
> I had added interactively some changes  using edit of a few junks (I tried to structure my big hacking into logical junks when committing).
> To test whether the partial commit would be consistent, I did a "git stash -k" before committing, and after committing I did a "git stash pop" to continue hacking.
> 
> Unfortunately I had a "Merge conflict". Looking at it, it is rather "interesting", however (meaning: I don't understand it).
> Here is how the conflict looks (to me both variants seem identical):

Yes, it does look "interesting". Did you make any changes between running "git stash -k" and "git stash pop"? I did wonder if there had been some whitespace changes where spaces were replaced with tabs or vice-versa ("git stash" uses "git apply" to create the stash so if you have apply.whitespace set to "fix" the stashed changes will not necessarily match those in the working copy) but diffing the two sides of the conflict does not show any changes.

Best Wishes
Phillip
Show 24 quoted lines
>          # pre-allocate translations and accesskeys
> <<<<<<< Updated upstream
>          foreach my $attr (LD_SEARCH_ATTR) {
>              $attr{$attr} = [translate_attr($attr), undef];
>              $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
>          }
>          foreach my $attr (LD_SEARCH_ATTR) {
> =======
>          foreach my $attr (LD_SEARCH_ATTR) {
>              $attr{$attr} = [translate_attr($attr), undef];
>              $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
>          }
>          foreach my $attr (LD_SEARCH_ATTR) {
>>>>>>>> Stashed changes
>              @n = (P_P_SRCH_ATTR . $attr, @{$attr{$attr}});
> 
> (the other conflict junks look reasonable)
> 
> Regards,
> Ulrich
> 
> 
> 
>
Ulrich Windl· Dec 19, 2022, 07:31 UTC · lore

Wtrlt: Antw: [EXT] Re: Strange "git stash pop" conflict (one chunk out of many)

Sorry, I forgot to reply to the list, too.
>>> Phillip Wood <phillip.wood123@gmail.com> schrieb am 17.12.2022 um 11:44 in
Nachricht <6c8e8271-432f-38e3-e70e-1445f874afc6@dunelm.org.uk>:
Show 18 quoted lines
> Hi Ulrich
> 
> On 15/12/2022 11:38, Ulrich Windl wrote:
>> Hi!
>> 
>> This is for a somewhat older git-2.26.2:
>> I had added interactively some changes  using edit of a few junks (I tried 
> to structure my big hacking into logical junks when committing).
>> To test whether the partial commit would be consistent, I did a "git stash 
> -k" before committing, and after committing I did a "git stash pop" to 
> continue hacking.
>> 
>> Unfortunately I had a "Merge conflict". Looking at it, it is rather 
> "interesting", however (meaning: I don't understand it).
>> Here is how the conflict looks (to me both variants seem identical):
> 
> Yes, it does look "interesting". Did you make any changes between 
> running "git stash -k" and "git stash pop"? I did wonder if there had

Of course I did: I did an --interactive add before (required to separate to edits affecting the same lines), then I stashed the rest. Commited that. The I switched to another branch doing a stash pop there to interactively add another fix like above. The switched back to the previous branch, did a rebase and then popped the remaining stash to continue.

Yes, I know it's a bad procedure, but frequently when adding a neew feature you find an fix bugs that aren't really related to that feature, so you want the unrelated fixes to go to another branch. Problably I don't use the full power of git yet (meaning: maybe there's an easier workflow).
Show 5 quoted lines
> been some whitespace changes where spaces were replaced with tabs or 
> vice-versa ("git stash" uses "git apply" to create the stash so if you 
> have apply.whitespace set to "fix" the stashed changes will not 
> necessarily match those in the working copy) but diffing the two sides 
> of the conflict does not show any changes.
I'm not aware that I did any white-space fixes in the hunk reported.

Regards, Ulrich

Show 29 quoted lines
> 
> Best Wishes
> 
> Phillip
> 
>>          # pre-allocate translations and accesskeys
>> <<<<<<< Updated upstream
>>          foreach my $attr (LD_SEARCH_ATTR) {
>>              $attr{$attr} = [translate_attr($attr), undef];
>>              $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
>>          }
>>          foreach my $attr (LD_SEARCH_ATTR) {
>> =======
>>          foreach my $attr (LD_SEARCH_ATTR) {
>>              $attr{$attr} = [translate_attr($attr), undef];
>>              $attr{$attr}->[1] = add_access_key($aks, 0, $attr{$attr}->[0]);
>>          }
>>          foreach my $attr (LD_SEARCH_ATTR) {
>>>>>>>>> Stashed changes
>>              @n = (P_P_SRCH_ATTR . $attr, @{$attr{$attr}});
>> 
>> (the other conflict junks look reasonable)
>> 
>> Regards,
>> Ulrich
>> 
>> 
>> 
>>

← back to recent threads