From: Ulrich Windl Date: Mon, 19 Dec 2022 07:31:28 GMT Subject: Wtrlt: Antw: [EXT] Re: Strange "git stash pop" conflict (one chunk out of many) Message-ID: <63A01350020000A100050851@gwsmtp.uni-regensburg.de> In-Reply-To: <63A012F0020000A10005084B@gwsmtp.uni-regensburg.de> Sorry, I forgot to reply to the list, too. >>> Phillip Wood 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 >> >> >> >>