Re: Heads-up: hard reset of the 'staging' branch

[Marius Bakke <marius@gnu.org>]

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

Marius Bakke <marius@gnu.org> writes:

> Marius Bakke <marius@gnu.org> 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.  :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]