Skip to content
Snippets Groups Projects
Commit 51844b8b5017 authored by Matt Harbison's avatar Matt Harbison
Browse files

merge: run update hook after the last wlock release

There were 2 test failures in 3.4-rc when running test-hook.t with the
largefiles extension enabled.  For context, the first is a commit hook:

  @@ -618,9 +621,9 @@
     $ echo 'update = hg id' >> .hg/hgrc
     $ echo bb > a
     $ hg ci -ma
  -  223eafe2750c tip
  +  d3354c4310ed+
     $ hg up 0
  -  cb9a9f314b8b
  +  223eafe2750c+ tip
     1 files updated, 0 files merged, 0 files removed, 0 files unresolved

   make sure --verbose (and --quiet/--debug etc.) are propagated to the local ui

In both cases, largefiles acquires the wlock before calling into core, which
also acquires the wlock.  The first case was fixed in 57f1dbc99631 by ensuring
the hook only runs after the lock has been fully released.  The full release is
important, because that is what writes dirstate to the disk, allowing external
hooks to see the result of the update.  This simply changes how the update hook
is called, so that it too is deferred until the lock is finally released.

There are many uses of mergemod.update(), but in terms of commands, it looks
like the following commands take wlock while calling mergemod.update(), and
therefore will now have their hook fired at a later time:

    backout, fetch, histedit, qpush, rebase, shelve, transplant

Unlike the others, fetch immediately unlocks after calling update(), so for all
intents and purposes, its hook invocation is not deferred (but the external hook
still sees the proper state).
parent 5e111acc1170
No related branches found
No related tags found
No related merge requests found
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment