Leo Famulari <l...@famulari.name> 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’.
