Page MenuHomePhabricator

Branch state not preserved during arc land with a failed pre-receive hook
Closed, DuplicatePublic

Description

Repro steps:

  1. Set up a pre-receive hook to block the push
  2. Configure arc with mutable history and no arc.land.update.default setting
  3. git checkout master^^
  4. git checkout -b testbranch
  5. # add a couple test commits
  6. arc land --trace

You will find that arc land leaves your branch (testbranch) with a temporary merge commit rather than rolling back to its original state.

Here is the relevant part of an example trace

    Revision 'D122269: Set up the symlinks for devsecrets and devkeys repo
    merge' has not been accepted. Continue anyway? [y/N] y

>>> [23] <conduit> differential.getcommitmessage() <bytes = 195>
>>> [24] <http> https://tails.corp.dropbox.com/api/differential.getcommitmessage
<<< [24] <http> 674,337 us
<<< [23] <conduit> 674,601 us
Landing revision 'D122269: Set up the symlinks for devsecrets and devkeys repo merge'...
>>> [25] <conduit> harbormaster.querybuildables() <bytes = 261>
>>> [26] <http> https://tails.corp.dropbox.com/api/harbormaster.querybuildables
<<< [26] <http> 509,651 us
<<< [25] <conduit> 509,917 us
Merging test into master
>>> [27] <exec> $ git merge --no-stat 'master' -m 'Automatic merge by '\''arc land'\'''
Merge made by the 'recursive' strategy.
<<< [27] <exec> 741,094 us
>>> [28] <exec> $ git checkout 'master'
<<< [28] <exec> 365,221 us
>>> [29] <exec> $ git merge --no-stat --squash --ff-only 'test'
<<< [29] <exec> 270,747 us
>>> [30] <exec> $ git commit -F '/private/var/folders/7b/mxbk8jt14tz60t48z7mff8y4xflnf9/T/auheltofroooc0wc/95409-SPRrJb'
<<< [30] <exec> 210,116 us
>>> [31] <event> land.willPushRevision <listeners = 0>
<<< [31] <event> 108 us
Pushing change...

>>> [32] <exec> $ git push 'origin' 'master'
Counting objects: 34, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (9/9), 910 bytes | 0 bytes/s, done.
Total 9 (delta 6), reused 0 (delta 0)
remote: ========Running pre-receive hooks=========
remote: Checking incoming changes for flagged constraints...
remote: Exception: This changeset MUST be reviewed and accepted in Phabricator before being pushed
To ssh://git@git.sjc.dropbox.com/server
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://git@git.sjc.dropbox.com/server'
<<< [32] <exec> 3,782,684 us
   PUSH FAILED!
>>> [33] <exec> $ git reset --hard HEAD^
<<< [33] <exec> 311,122 us
>>> [34] <exec> $ git checkout 'test'
<<< [34] <exec> 351,034 us
>>> [35] <exec> $ git submodule update --init --recursive
<<< [35] <exec> 346,459 us
Switched back to branch test.
Usage Exception: 'git push' failed! Fix the error and run 'arc land' again.

Logging metrics for 'arc_result' as 'array(
  'arc_command' => 'land',
  'arc_exception_message' => '\'git push\' failed! Fix the error and run \'arc land\' again.',
)'

[2015-07-13 18:14:48] EXCEPTION: (ArcanistUsageException) 'git push' failed! Fix the error and run 'arc land' again. at [<arcanist>/src/workflow/ArcanistLandWorkflow.php:1024]
  #0 ArcanistLandWorkflow::push() called at [<arcanist>/src/workflow/ArcanistLandWorkflow.php:202]
  #1 ArcanistLandWorkflow::run() called at [<arcanist>/scripts/arcanist.php:378]

Event Timeline

nipunn raised the priority of this task from to Needs Triage.
nipunn updated the task description. (Show Details)
nipunn added projects: Arcanist, Restricted Project.
nipunn added subscribers: nipunn, jhurwitz, angie and 2 others.

As a tangent, this flow also leaks slightly in that the end of arc land output says "you can get this commit back by..." and the SHA that it tells you is the SHA of the merged commit, not the tip of the branch that you originally had.

It is currently intentional that arc land does not restore state after a push failure.

Historically, this decision was made in a Facebook environment with slow pulls (SVN / Git bridging) and an unreliable network (Facebook corpnet randomly dropped many internal packets for a long period of time), so the remedy after git push was often to just run git push again without other changes. This was also made at a time when Facebook's bizarre / obviously-wrong use cases ("run an unreliable internal network", "drop 80% of internal mail", "cluster Phabricator but put each service tier as physically far apart from one another as possible") heavily influenced upstream technical decisionmaking.

This decision is likely not the correct one outside of "if you have Facebook problems", and I intend to reverse it in the future. T3855 discusses this, and some related changes. I'm going to merge this there.

angie moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 14 2015, 6:01 PM