Open emilio opened 2 years ago
Hmm, after re-fetching and rebasing on top of central, it went away :/
$ g fetch mozilla
From hg::https://hg.mozilla.org/mozilla-unified
- [deleted] (none) -> mozilla/branches/default/b379b56bf47cdfb9149b134dd1f9cd4850d72cfc
Reading 29 changesets
Reading and importing 29 manifests
Reading and importing 99 revisions of 94 files
Importing 29 changesets
Checking 94 imported file root and head revisions
1517c4c922f6b..a15bc5c2b86fa bookmarks/autoland -> mozilla/bookmarks/autoland
c35054ab141b4..99d699a1dac13 bookmarks/beta -> mozilla/bookmarks/beta
1f5816249c4df..8772c3a3f24c6 bookmarks/central -> mozilla/bookmarks/central
* [new branch] branches/default/e4c79d4b676cca6003afdda79ef3c061f83352db -> mozilla/branches/default/e4c79d4b676cca6003afdda79ef3c061f83352db
1517c4c922f6b..a15bc5c2b86fa branches/default/tip -> mozilla/branches/default/tip
Can you check your reflog to find where you were at before and try again from there?
This is on 1f5816249c4dfccedfe5f79682f1fc117d5a92df (hg: 0e384d802c84057a296e06a6b05f0326ed8c46e3) plus a few patches, attached below. patches.bundle.zip
So what happens in your case is that the mercurial changeset git-cinnabar creates for 316f240032ff4832a24e3340b3e86af33d1f7030 is f0828943d68496487c9f8753b5f4632ab4697deb, and your metadata already knows that changeset as ae7d385ae0d20ede07b9c55909f1e86382094443. Those are two commits with the same content, same parent, same author date, same commit date. The only difference is that the newer one is gpg-signed. If you commit --amend, the problem goes away.
That's something cinnabar could handle better, but it's an uncommon edge case. It also only happens because the metadata for your try pushes is kept, which is also uncommon (it shouldn't happen unless you set cinnabar.data
or remote.$remote.cinnabar-data
to always
; or did you push this to another repo?).
Additionally, and related to this, your clone has diverged from a pure cinnabar clone because you've directly pushed gpg-signed commits to central or autoland or wherever, and the corresponding changesets don't carry the gpg signature, so when cloning from scratch, the commits are different. Your repo seems otherwise consistent, but I have a full fsck still running, which will tell more.
(it shouldn't happen unless you set cinnabar.data or remote.$remote.cinnabar-data to always ; or did you push this to another repo?).
Oh, maybe you git cinnabar fetch
'ed from try? That would do it...
Yeah, I fetch from try relatively frequently (e.g., my patch fails on macOS, I fix it on my Mac, push to try again and update the patch stack on my Linux machine as well)
Ok, so fetching from try storing metadata is #82. A workaround is to run git cinnabar rollback after git cinnabar fetch.
The easiest in your case, though, is to disable gpg-signing on your cinnabar repo.
Summarizing the things that should be fixed short-ish term for future-me's sake:
I see. Yeah I've pushed test fixes to autoland (with sheriff's permission), so that explains that divergence.