On Wed, Aug 03, 2016 at 07:56:05PM +0200, Ludovic Courtès wrote: > Leo Famulari <l...@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?
