Marius Bakke writes: > Marius Bakke writes: > >> I have pushed a 'staging2' branch where I did the following: >> >> 1) git rebase -i --rebase-merges 8229ce3116c1f522c7157ab2dcd50dc2d765686a~ >> >> 2) Moved 8229ce3116c1f522c7157ab2dcd50dc2d765686a after >> f00270d35a6ca814903a9392caedc29d44959088 (the first merge that includes >> .guix-authorizations) -- it was "one step down" in Magits interactive >> rebase menu. >> >> 3) "solved" three merge conflicts (actually git rerere remembered the >> resolutions, and I could have used git rebase --rerere-autoupdate to >> make the process entirely automatic). >> >> I intend to move the current 'staging' branch to 'staging-old', and >> rename 'staging2' to 'staging' once I'm fully confident in the result >> and resolution. > > Of course I sent this before actually testing the branch! 'git rerere' > had forgotten a very important merge resolution from > 354880e7209a2aec0360dfe5b08b1873c084e2dd: the "tzdata-for-tests" package > needs to be kept on version 2019c during that merge to prevent a > full rebuild via "python". > > I will do a new rebase tomorrow and make sure each of the merges are > correct. So the three merges that needed rebasing were: f00270d35a6ca814903a9392caedc29d44959088 1ffd7a7e514072039a1bc92eb1a09b8119b06c91 34d8640b1a85198fa060a6ddbdbf10ad6e2415ea During the first, apart from the _actual_ (git style) conflict, tzdata-for-tests needed manual merging as mentioned earlier. I solved it by "git checkout f00270d35 -- gnu/packages/base.scm" during the merge. For 1ffd7a7e there was another "hidden" (not detected by git) conflict in gnu/packages/cups.scm, though not as grave (only a leftover variable). Solved by "git checkout 1ffd7a7e -- gnu/packages/cups.scm". 34d8640b1 did not have any surprise conflicts. The new rebased merges are: 9edb3f66fd807b096b48283debdcddccfea34bad aa13c5657d4f8b5dd52beda88a9a8ccc59ebca86 8a7a5dc7805f4628e60f90af6b2416f951d0c034 They should be identical to the previous merges, with one difference: the first merge no longer has a conflict in linux.scm because it was moved to the rebased ddcfc467968d8367e62cb24cbc9e89bb5af0fe6d. The new 'staging' branch have these rebased merges and is identical to the previous 'staging' (excluding .git). The previous branch is available as 'staging-old' for the time being in case anyone wants to verify. In the future I'll be annotating such "hidden" merge conflicts in the commit message somehow (perhaps using the regular ChangeLog style). I hope we don't need to perform branch surgery again, but there are legitimate cases for making similar merges to different branches. Another key takeaway is that 'git rerere' does not remember any "manual" merge resolutions: it only saves resolutions for things that would introduce the regular git conflict markers. If you read this far, I'm sorry! Happy to say the situation is under control and the staging branch will continue its normal operation shortly. :-)