bug#70456: Request for merging "core-updates" branch

[Maxim Cournoyer]

Hi,

Christopher Baines <mail@cbaines.net> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>> I'm also really confused by what commits appear to be on the branch,
>> take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one
>> core-updates, but it's a duplicate of
>> e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to
>> master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467,
>> which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on
>> master.
>
> I've worked out at least when these two werid commits turned up on
> core-updates.
>
> 12b15585a7 is mentioned here:
>   https://lists.gnu.org/archive/html/guix-commits/2023-09/msg00955.html
>
> and 28d1413095 is mentioned here:
>   https://lists.gnu.org/archive/html/guix-commits/2024-03/msg00381.html
>
>
> With the changes last month in March, I was going to suggest deleting
> the branch and then re-creating from f205179ed2 and trying to re-apply
> the changes that should be on core-updates, while avoiding any
> "duplicate" commits. However, I'm not even sure where to being with the
> ~5000 commits pushed in September, at least one of them is a duplicate
> of a commit on master, but I'm not sure how many of the other ~5000 are.
>
> For comparison, I did a merge of master in to core-updates today, and
> this is what it shows up like on guix-commits:
>
>   https://lists.gnu.org/archive/html/guix-commits/2024-04/msg01209.html
>
> There are only two new revisions, the ed update I pushed, and the merge
> commit, which is what a merge should look like as far as I'm aware.

I think probably what happened is that in the middle of a merge of
master -> core-updates (which entails sometimes painful conflicts
resolution), a new commit pushed to core-updates, and to be able to push
the resulting local branch (including the thousands of commits from the
merge commit) got rebased on the remote core-updates.

Perhaps another merge commit appeared on the remote around the same
time, which would explain the duplicates.

While I agree it's messy to have 5000 of duplicated commits, I'm not
sure attempting to rewrite the branch, which has seen a lot of original
commits, is a good idea (it'd be easy to have some good commits fall
into cracks, leading to lost of work).

I'd rather we take this experience as a strong reminding that rebasing
merge commits should be avoided at all costs (git already issues a
warning, IIRC).  As you suggested, the next time a situation like this
happens (locally prepared merge commit with new commits made to the
remote branch), merging the remote into the local branch is probably a
nicer solution.

-- 
Thanks,
Maxim