I have a commit hook named showrev: from mercurial.node import short def print_commit(ui, repo, node=None, **kwargs): ctx = repo[node] ui.write("Committed revision %s:%s %s by %s\n" % (ctx.rev(), short(ctx.node()), ctx.branch(), ctx.user())) When I use histedit to fold any revisions I get errors like: error: commit.showrev hook raised an exception: unknown revision 'e4ddc3643fb10c110659f30b37759caac521cd08' bisect shows that the bad revision is 4778f398ec83 Script to reproduce: #!/bin/sh rm -rf hg-temp mkdir hg-temp cd hg-temp hg init touch file1 && hg add file1 hg commit -m file1 touch file2 && hg add file2 hg commit -m file2 hg histedit 0 # fold two revisions
When does your hook run?
ah, it's a hook on 'commit', and I presume holding the lock for the duration of the histedit delays the commit. Not sure if this is BC breakage, but try a pretxncommit hook.
With pretxncommit there are no errors.
What (is probably happening) here is: lock: transaction is created: histedit create temporary commit "pretxncommit" hooks run transaction is closed: "commit" hook are scheduled for hook release temporary commit are stripped unlock: "commit" hook is run It is going to be hard to craft a clean solution quickly. But this smell like a regression and we should probably offer and acceptable work around.
regression -> urgent Is this specific to (totally unsupported) internal Python hooks or does it also break with external hooks? I think the commit hook(s) are getting deferred to lock release, at which time temporary commits may have disappeared?
The internal hook crash because the revision is not found. External hook will be run with a HG_NODE containing an unknown hash.
Fixed by http://selenic.com/repo/hg/rev/eb315418224c Pierre-Yves David <pierre-yves.david@fb.com> hook: protect commit hooks against stripping of temporary commit (issue4422) History rewriting commands like histedit tend to use temporary commits. They may schedule hook execution on these temporary commits for after the lock has been released. But temporary commits are likely to have been stripped before the lock is released (and the hook run). Hook executed for missing revisions leads to various crashes. We disable hooks execution for revision missing in the repo. This provides a dirty but simple fix to user issues. (please test the fix)
It looks to be fixed. Thanks!
Bulk testing -> fixed