Re: core-updates merged!

[Leo Famulari <leo@famulari.name>]

On Wed, Aug 03, 2016 at 07:56:05PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > On Wed, Aug 03, 2016 at 06:42:34PM +0200, Ludovic Courtès wrote:
> >> I think you should start from the pre-merge ‘core-updates-next’, sign
> >> commits that are unsigned (I thought Manolis signed them all on the last
> >> rebase?), then merge, and finally push.
> >
> > Unfortunately, signing old commits causes subsequent history to be
> > rewritten, and the subsequent signatures are lost. I would have to
> > re-sign commits all the way back to June (for aebd383). And Git users'
> > local history would become invalid.
> 
> Yeah, but despite lacking the ‘wip-’ prefix as we usually do, this
> branch was “rebaseable”, so I think it’s OK.
> 
> Hopefully that will no longer happen in the future.
> 
> > 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.

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 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?