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

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

[Ulrich Windl]

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

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

[Bagas Sanjaya]

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...

-- 
An old man doll... just what I always wanted! - Clara

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

[Phillip Wood]

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 
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

>          # 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
> 
> 
> 
> 

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

[Phillip Wood]

On 17/12/2022 01:58, Bagas Sanjaya wrote:
> 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

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

[Ulrich Windl]

>>> Bagas Sanjaya <bagasdotme@gmail.com> schrieb am 17.12.2022 um 02:58 in
Nachricht <ced6bacc-3d77-4d24-33f3-a93d2ae7a131@gmail.com>:
> 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

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

[Ulrich Windl]

[-- Attachment #1: Type: text/plain, Size: 46 bytes --]

Sorry, I forgot to reply to the list, too.


[-- Attachment #2: Type: message/rfc822, Size: 3257 bytes --]

From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <phillip.wood@dunelm.org.uk>
Subject: Antw: [EXT] Re: Strange "git stash pop" conflict (one chunk out of many)
Date: Mon, 19 Dec 2022 08:29:52 +0100

>>> Phillip Wood <phillip.wood123@gmail.com> schrieb am 17.12.2022 um 11:44 in
Nachricht <6c8e8271-432f-38e3-e70e-1445f874afc6@dunelm.org.uk>:
> 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).

> 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

> 
> 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
>> 
>> 
>> 
>>