Re: core-updates merged!

[Ludovic Courtès]

Leo Famulari <address@hidden> skribis:

>> > I think we are hitting something like the problem I warned about here:
>> > http://lists.gnu.org/archive/html/guix-devel/2016-07/msg01220.html
>> 
>> Yes, that’s annoying, but it’s a one-time transitional cost.
>
> Just to clarify, I would be re-signing (with my own key) and rebasing
> all commits that were made on the master branch and merged on
> core-updates-next, going back to sometime in June 2016.

I think core-updates-next is just a dozen commits or so, right?

> Whenever we merge this core-updates-next branch back into master, the
> master branch's history will be rewritten, starting with aebd383d0.
> Right? Or am I misunderstanding?

I think we should remerge core-updates-next on top of master, making it
the new core-updates.

>From there on, we will not rebase core-updates and only do merges in
that branch, as usual.

> I tried it, to see what would happen.
>
> $ git rebase aebd383d04b351465cfb14e4fd0949b67d4b282e^ --exec "git commit 
> --amend --no-edit --gpg-sign" || git rebase --abort
>
> But for some reason, it ends up trying to work on commits from February
> (starting at "build-system/gnu: Do not patch symlinks"), and then fails
> to apply the commit that updates Python 2 to 2.7.11. Nothing should fail
> to apply, since I'm not changing any files. Am I doing it wrong, or is
> it a bug in Git? Perhaps some complication rebasing through previous
> merges?

Hmm.  Perhaps the explanation is the merged commit that I screwed, which
I’ll write about just now.

Ludo’.