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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--- Begin Message ---
>>> Phillip Wood <phillip.wood123@xxxxxxxxx> schrieb am 17.12.2022 um 11:44 in
Nachricht <6c8e8271-432f-38e3-e70e-1445f874afc6@xxxxxxxxxxxxx>:
> 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
>> 
>> 
>> 
>> 





--- End Message ---

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux