Nightly rustc warns about the RevlogEntry::rev field not being
used. Rather than removing it, I added an accessor since it seems
useful to be able to get the entry's revision.
Details
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
Hmm, I noticed that this disappeared from Phabricator, but I didn't see any updates when I pulled from hg-commited. I see that same commit I sent for review is available in hg-committed (https://www.mercurial-scm.org/repo/hg-committed/rev/2caf1de2fbe4). That suggests that I pushed it myself, but the only recent hg push in my blackbox is this:
2021-10-01 09:19:43.206487 -0700 martinvonz @789475ef2b224fd5d70226889bb5b68e33a069ef (3235472) [command]> push -r .
That commit is the one I pushed after I queued Raphaël's D11549.
So, should I prune my commit and resend this review? Raphaël's already accepted it, so it seems okay to me to just rebase onto @ and push, but I don't want to abuse my access rights.
(I also need to figure out how if that push was what caused my commit to be pushed, and if that's because of some internal extension I use.)
I'm not sure what the issue is, I pushed the commit after importing it using phabimport?
That's 2caf1de2 that you pushed? That commit is not an ancestor of @, which points to 789475ef (my queued version of your commit).
The obslog for my commit looks like this:
$ hg obslog 2caf1de2 o 2caf1de2 martinvonz D11548 2021-10-01 08:44 -0700 | hg-core: silence dead-code warning by adding RevlogEntry::revion() accessor | rewritten from f6b47a535937 using phabsend by martinvonz at 2021-10-01 08:45 -0700 | x f6b47a53 martinvonz obsolete 2021-10-01 08:44 -0700 rewritten using phabsend as 97020:2caf1de2fbe4 hg-core: silence dead-code warning by adding RevlogEntry::revion() accessor
There's no mention of it being rewritten by you there.
How does it look on your machine?
Oh, could it be that the import was lossless and hg phabimport thus created the same commit id as I already had? In that case the only problem is that the default branch has diverged (did you hg push -f?). I'll fix that.
Why would it if it created the same changeset?
How does it look on your machine?
It looks like this:
$ hg obslog -r 2caf1de2 o 2caf1de2fbe4 (49007) hg-core: silence dead-code warning by adding RevlogEntry::revion() accessor
My change that removes the dead code is 8947ac1fc26d8cff29caf301d9e3c0fd0aef7ecf if that matters.
Seems like a bug that we could both push an updated @ without --force, but everything else is clear now. I think it's just really rare that I send a commit without some stuff in the changeset extras that makes hg phabimport never produce the same commit id.
I see you've rewritten both changesets, but the state looks okay now. However the @ bookmark is at 789475ef2b224fd5d70226889bb5b68e33a069ef instead of fecfea658127b41be1e1ae4782bc9b12ae8dcefc. What's up with that?
Huh, that's weird. It's on fecfea65 in my repo, but according to https://www.mercurial-scm.org/repo/hg-committed/graph, it's b4d7b04e3c88. So it seems that your repo, hg-commited, and my repo all show it in different places. I wonder if something about bookmark exchange has been broken by some recent change.
Also note that that commit in hg-committed is an obsolete version of your merge commit.