Page MenuHomePhabricator

Pass mercurial PENDING environment into log command during prepushkey hook

Authored by cspeckmim on Feb 2 2017, 7:51 AM.
Referenced Files
F12163374: D17296.diff
Wed, Sep 6, 9:29 PM
F12145949: D17296.id41602.diff
Thu, Aug 31, 10:48 PM
F12141445: D17296.diff
Tue, Aug 29, 7:08 PM
Unknown Object (File)
Aug 17 2023, 10:02 AM
Unknown Object (File)
Jul 15 2023, 11:38 PM
Unknown Object (File)
Jul 14 2023, 11:41 AM
Unknown Object (File)
Jul 11 2023, 4:26 PM
Unknown Object (File)
Jul 5 2023, 3:25 PM



I'm trying to dig into fixing some of these mercurial issues (to try and properly work around bundle2 for the time being), and I came across this issue again (T9639).

My set up is

ClientMercurial 4.0
ServerMercurial 4.1 (SSH)

The Mercurial prepushkey hook is failing when pushing a commit which advances a bookmark. This fails when client/server are using bundle2. It appears to be failing due to not recognizing the new commit being added. It's unclear why this seems to be broken only when using bundle2.

This change passes in the HG_PENDING environment variable when running the hg log command so that it can reference the commit being added. Note that this is the same strategy already being used in DiffusionCommitHookEngine.findMercurialChangegroupRefUpdates().

Refs T9639

Test Plan
  1. I ensured mercurial repository hosted by phabricator has the master bookmark (hosted over SSH)
  2. I cloned the repository locally using hg-4.1
  3. I ensured client has master bookmark active
  4. I created a new commit from client onto the repository and verified the master bookmark advances to the newly created commit
cspeckrun@specktop ~/P/n/hgtest> hg out
comparing with ssh://phab-devel.code/diffusion/HGTEST/hgtest/
searching for changes
changeset:   59:c26f89a8ddf0
bookmark:    master
tag:         tip
user:        cspeck
date:        Thu Feb 02 01:27:16 2017 -0500
summary:     MAINT: Test pushing over ssh
  1. I pushed the commit up to phabricator with hg pus -r master
  2. I veriied the push succeeded
cspeckrun@specktop ~/P/n/hgtest> hg pus -r master
pushing to ssh://phab-devel.code/diffusion/HGTEST/hgtest/
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
updating bookmark master

Diff Detail

rP Phabricator
Lint Passed
Tests Skipped
Build Status
Buildable 15500
Build 20433: Run Core Tests
Build 20432: arc lint + arc unit

Event Timeline

I suspect the current strategy is based partially on a misunderstanding of the underlying issue, and that T12071 is the better/more general fix here.

  • Is your variables_order currently set to something with no E in it in php.ini?
  • If you change it to EGPCS, does that resolve the issue without code changes?

If this is rooted in variables_order, I'd rather just tell users to fix that than keep playing environmental whack-a-mole.

("The current strategy" being doing this $_ENV shell game, i.e. the fix I pursued in D7763 wasn't the best fix.)

I will give that a try. My understanding of the problem/solution here is that when prepushkey hook is invoked by mercurial, it's within an environment that contains the changes of the transaction being requested, all of that being communicated via the environment variables. When this hook runs it shells out to execute some other mercurial commands to inspect the repository it loses that environment and is no longer operating within the environment of the transaction (resulting in the error about an unknown revision which is the one being pushed). I'm not really familiar with PHP, variables_order or $_ENV. Is the E thing for variables_order something that causes sub-processes to inherit the environment?

The variables_order stuff is hard to explain concisely, but the very brief version is that my current belief is:

  • With E, everything works like you would expect it to in a sane environment. In particular, the entire environment is passed to subprocesses by default.
  • Without E, many interesting problems occur.

At this point we have a fairly substantial amount of code to mitigate those "interesting problems", some of which causes other interesting problems. I currently believe the real root problem is a missing E.

Adding E to variables_order seems to fix it!

  1. I reverted all files in the phabricator repository
  2. I stopped all phab services
  3. I modified /etc/php.ini to set variables_order = EGPCS
  4. I restarted all phab services
  5. On client cloned the mercurial repository
  6. On client I created a new commit and advanced the master bookmar
  7. On client I hg pus -r master
cspeck@speckimac ~/S/hgtest> hg pus -r master
pushing to ssh://repo-testing.code/source/hgtest/
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

Great! I'm not going to try to sneak anything into the release, but I'll see about getting setup guidance for T12071 in shortly. I'm still not 100% sure what to do about arc, but I think setup guidance is the right strategy for Phabricator.

(The guidance will basically say "add E or nothing will work", and then we'll start assuming that E has been set.)