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]

 



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







[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