Git pre-push hooks









up vote
91
down vote

favorite
25












I would like to run a unit-tests before every git push and if tests fails, cancel the push, but I can't even find pre-push hook, there is pre-commit and pre-rebase only.










share|improve this question





















  • related: stackoverflow.com/questions/31681746
    – tkruse
    Jul 26 at 5:55














up vote
91
down vote

favorite
25












I would like to run a unit-tests before every git push and if tests fails, cancel the push, but I can't even find pre-push hook, there is pre-commit and pre-rebase only.










share|improve this question





















  • related: stackoverflow.com/questions/31681746
    – tkruse
    Jul 26 at 5:55












up vote
91
down vote

favorite
25









up vote
91
down vote

favorite
25






25





I would like to run a unit-tests before every git push and if tests fails, cancel the push, but I can't even find pre-push hook, there is pre-commit and pre-rebase only.










share|improve this question













I would like to run a unit-tests before every git push and if tests fails, cancel the push, but I can't even find pre-push hook, there is pre-commit and pre-rebase only.







git hook






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 16 '10 at 16:03









sheepwalker

5241616




5241616











  • related: stackoverflow.com/questions/31681746
    – tkruse
    Jul 26 at 5:55
















  • related: stackoverflow.com/questions/31681746
    – tkruse
    Jul 26 at 5:55















related: stackoverflow.com/questions/31681746
– tkruse
Jul 26 at 5:55




related: stackoverflow.com/questions/31681746
– tkruse
Jul 26 at 5:55












7 Answers
7






active

oldest

votes

















up vote
18
down vote



accepted










I would rather run the test in a pre-commit-hook. Because the change is already recorded when committing. Push and pull only exchange information about already recorded changed. If a test fails you would already have a "broken" revision in your repository. Whether you're pushing it or not.






share|improve this answer
















  • 144




    I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
    – Cascabel
    Nov 16 '10 at 18:03










  • I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
    – ordnungswidrig
    Nov 17 '10 at 8:27











  • I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
    – sheepwalker
    Dec 8 '10 at 11:51







  • 4




    Down voted because - while informative - it completely ignores the OP's question.
    – The Dembinski
    Jan 16 '17 at 18:24







  • 4




    @calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
    – The Dembinski
    May 8 '17 at 16:16

















up vote
183
down vote













Git got the pre-push hook in the 1.8.2 release.



Sample pre-push script: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample



1.8.2 release notes talking about the new pre-push hook: https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt






share|improve this answer


















  • 1




    Hey dude.. Thanks.. :)
    – Gaurav Agarwal
    Feb 6 '14 at 12:52






  • 1




    @manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
    – igrek
    Jun 19 '14 at 13:51










  • @igrek did you find a solution to the connection closing issue?
    – Mario Estrada
    Apr 27 '15 at 3:54










  • @MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
    – igrek
    Apr 28 '15 at 7:12







  • 4




    This needs to be the accepted answer.
    – The Dembinski
    Jan 16 '17 at 18:25

















up vote
19
down vote














Git got the pre-push hook in the 1.8.2 release.




Pre-push hooks are what I needed along with pre-commit hooks. Apart from protecting a branch, they can also provide extra security combined with pre-commit hooks.



And for an example on how to use (taken and adopted and enhanced from this nice entry)



Simple example to login to vagrant, run tests and then push



#!/bin/bash
# Run the following command in the root of your project to install this pre-push hook:
# cp git-hooks/pre-push .git/hooks/pre-push; chmod 700 .git/hooks/pre-push

CMD="ssh vagrant@192.168.33.10 -i ~/.vagrant.d/insecure_private_key 'cd /vagrant/tests; /vagrant/vendor/bin/phpunit'"
protected_branch='master'

# Check if we actually have commits to push
commits=`git log @u..`
if [ -z "$commits" ]; then
exit 0
fi

current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/(.*),1,')

if [[ $current_branch = $protected_branch ]]; then
eval $CMD
RESULT=$?
if [ $RESULT -ne 0 ]; then
echo "failed $CMD"
exit 1
fi
fi
exit 0


As you can see the example uses a protected branch, subject of the pre-push hook.






share|improve this answer



























    up vote
    13
    down vote













    If you are using the command line, the easiest way to do this is to write a push script that runs your unit tests and, if they succeed, completes the push.



    Edit



    As of git 1.8.2 this answer is outdated. See manojlds's answer above.






    share|improve this answer






















    • do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
      – sheepwalker
      Nov 16 '10 at 16:22






    • 1




      @sheepwalker: s/pull/push/, and use an alias to make it nice and short.
      – Cascabel
      Nov 16 '10 at 18:02










    • @sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
      – kubi
      Nov 16 '10 at 20:08


















    up vote
    7
    down vote













    There isn't a hook for it, because a push isn't an operation that modifies your repository.



    You can do the checks on the receiving side though, in the post-receive hook. That is where you would usually reject an incoming push. Running unit tests might be a little intensive to do in a hook, but that's up to you.






    share|improve this answer



























      up vote
      5
      down vote













      For the record, there is a patch to Git 1.6 that adds a pre-push hook. I don't know whether it works against 1.7.



      Rather than mess with that, you could run push script like @kubi recommended. You could also make it a Rake task instead so it's in your repo. ruby-git could help with this. If you check the target repo, you could run tests only when pushing to the production repo.



      Finally, you could run your tests in your pre-commit hook but check for what branch is being committed to. Then you could have a, say, a production branch that requires all tests pass before accepting a commit but your master doesn't care. limerick_rake may be useful in that scenario.






      share|improve this answer






















      • thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
        – sheepwalker
        Mar 1 '11 at 15:56

















      up vote
      0
      down vote













      The script linked by the highly-voted answer shows the parameters etc to the pre-push hook ($1 is remote name, $2 URL) and how to access the commits (lines read from stdin have structure <local ref> <local sha1> <remote ref> <remote sha1>)



      #!/bin/sh

      # An example hook script to verify what is about to be pushed. Called by "git
      # push" after it has checked the remote status, but before anything has been
      # pushed. If this script exits with a non-zero status nothing will be pushed.
      #
      # This hook is called with the following parameters:
      #
      # $1 -- Name of the remote to which the push is being done
      # $2 -- URL to which the push is being done
      #
      # If pushing without using a named remote those arguments will be equal.
      #
      # Information about the commits which are being pushed is supplied as lines to
      # the standard input in the form:
      #
      # <local ref> <local sha1> <remote ref> <remote sha1>
      #
      # This sample shows how to prevent push of commits where the log message starts
      # with "WIP" (work in progress).

      remote="$1"
      url="$2"

      z40=0000000000000000000000000000000000000000

      while read local_ref local_sha remote_ref remote_sha
      do
      if [ "$local_sha" = $z40 ]
      then
      # Handle delete
      :
      else
      if [ "$remote_sha" = $z40 ]
      then
      # New branch, examine all commits
      range="$local_sha"
      else
      # Update to existing branch, examine new commits
      range="$remote_sha..$local_sha"
      fi

      # Check for WIP commit
      commit=`git rev-list -n 1 --grep '^WIP' "$range"`
      if [ -n "$commit" ]
      then
      echo >&2 "Found WIP commit in $local_ref, not pushing"
      exit 1
      fi
      fi
      done

      exit 0





      share|improve this answer




















        Your Answer






        StackExchange.ifUsing("editor", function ()
        StackExchange.using("externalEditor", function ()
        StackExchange.using("snippets", function ()
        StackExchange.snippets.init();
        );
        );
        , "code-snippets");

        StackExchange.ready(function()
        var channelOptions =
        tags: "".split(" "),
        id: "1"
        ;
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function()
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled)
        StackExchange.using("snippets", function()
        createEditor();
        );

        else
        createEditor();

        );

        function createEditor()
        StackExchange.prepareEditor(
        heartbeatType: 'answer',
        convertImagesToLinks: true,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: 10,
        bindNavPrevention: true,
        postfix: "",
        imageUploader:
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        ,
        onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        );



        );













        draft saved

        draft discarded


















        StackExchange.ready(
        function ()
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f4196148%2fgit-pre-push-hooks%23new-answer', 'question_page');

        );

        Post as a guest















        Required, but never shown

























        7 Answers
        7






        active

        oldest

        votes








        7 Answers
        7






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes








        up vote
        18
        down vote



        accepted










        I would rather run the test in a pre-commit-hook. Because the change is already recorded when committing. Push and pull only exchange information about already recorded changed. If a test fails you would already have a "broken" revision in your repository. Whether you're pushing it or not.






        share|improve this answer
















        • 144




          I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
          – Cascabel
          Nov 16 '10 at 18:03










        • I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
          – ordnungswidrig
          Nov 17 '10 at 8:27











        • I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
          – sheepwalker
          Dec 8 '10 at 11:51







        • 4




          Down voted because - while informative - it completely ignores the OP's question.
          – The Dembinski
          Jan 16 '17 at 18:24







        • 4




          @calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
          – The Dembinski
          May 8 '17 at 16:16














        up vote
        18
        down vote



        accepted










        I would rather run the test in a pre-commit-hook. Because the change is already recorded when committing. Push and pull only exchange information about already recorded changed. If a test fails you would already have a "broken" revision in your repository. Whether you're pushing it or not.






        share|improve this answer
















        • 144




          I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
          – Cascabel
          Nov 16 '10 at 18:03










        • I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
          – ordnungswidrig
          Nov 17 '10 at 8:27











        • I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
          – sheepwalker
          Dec 8 '10 at 11:51







        • 4




          Down voted because - while informative - it completely ignores the OP's question.
          – The Dembinski
          Jan 16 '17 at 18:24







        • 4




          @calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
          – The Dembinski
          May 8 '17 at 16:16












        up vote
        18
        down vote



        accepted







        up vote
        18
        down vote



        accepted






        I would rather run the test in a pre-commit-hook. Because the change is already recorded when committing. Push and pull only exchange information about already recorded changed. If a test fails you would already have a "broken" revision in your repository. Whether you're pushing it or not.






        share|improve this answer












        I would rather run the test in a pre-commit-hook. Because the change is already recorded when committing. Push and pull only exchange information about already recorded changed. If a test fails you would already have a "broken" revision in your repository. Whether you're pushing it or not.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 16 '10 at 16:48









        ordnungswidrig

        2,82011326




        2,82011326







        • 144




          I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
          – Cascabel
          Nov 16 '10 at 18:03










        • I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
          – ordnungswidrig
          Nov 17 '10 at 8:27











        • I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
          – sheepwalker
          Dec 8 '10 at 11:51







        • 4




          Down voted because - while informative - it completely ignores the OP's question.
          – The Dembinski
          Jan 16 '17 at 18:24







        • 4




          @calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
          – The Dembinski
          May 8 '17 at 16:16












        • 144




          I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
          – Cascabel
          Nov 16 '10 at 18:03










        • I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
          – ordnungswidrig
          Nov 17 '10 at 8:27











        • I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
          – sheepwalker
          Dec 8 '10 at 11:51







        • 4




          Down voted because - while informative - it completely ignores the OP's question.
          – The Dembinski
          Jan 16 '17 at 18:24







        • 4




          @calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
          – The Dembinski
          May 8 '17 at 16:16







        144




        144




        I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
        – Cascabel
        Nov 16 '10 at 18:03




        I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
        – Cascabel
        Nov 16 '10 at 18:03












        I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
        – ordnungswidrig
        Nov 17 '10 at 8:27





        I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
        – ordnungswidrig
        Nov 17 '10 at 8:27













        I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
        – sheepwalker
        Dec 8 '10 at 11:51





        I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
        – sheepwalker
        Dec 8 '10 at 11:51





        4




        4




        Down voted because - while informative - it completely ignores the OP's question.
        – The Dembinski
        Jan 16 '17 at 18:24





        Down voted because - while informative - it completely ignores the OP's question.
        – The Dembinski
        Jan 16 '17 at 18:24





        4




        4




        @calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
        – The Dembinski
        May 8 '17 at 16:16




        @calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
        – The Dembinski
        May 8 '17 at 16:16












        up vote
        183
        down vote













        Git got the pre-push hook in the 1.8.2 release.



        Sample pre-push script: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample



        1.8.2 release notes talking about the new pre-push hook: https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt






        share|improve this answer


















        • 1




          Hey dude.. Thanks.. :)
          – Gaurav Agarwal
          Feb 6 '14 at 12:52






        • 1




          @manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
          – igrek
          Jun 19 '14 at 13:51










        • @igrek did you find a solution to the connection closing issue?
          – Mario Estrada
          Apr 27 '15 at 3:54










        • @MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
          – igrek
          Apr 28 '15 at 7:12







        • 4




          This needs to be the accepted answer.
          – The Dembinski
          Jan 16 '17 at 18:25














        up vote
        183
        down vote













        Git got the pre-push hook in the 1.8.2 release.



        Sample pre-push script: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample



        1.8.2 release notes talking about the new pre-push hook: https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt






        share|improve this answer


















        • 1




          Hey dude.. Thanks.. :)
          – Gaurav Agarwal
          Feb 6 '14 at 12:52






        • 1




          @manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
          – igrek
          Jun 19 '14 at 13:51










        • @igrek did you find a solution to the connection closing issue?
          – Mario Estrada
          Apr 27 '15 at 3:54










        • @MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
          – igrek
          Apr 28 '15 at 7:12







        • 4




          This needs to be the accepted answer.
          – The Dembinski
          Jan 16 '17 at 18:25












        up vote
        183
        down vote










        up vote
        183
        down vote









        Git got the pre-push hook in the 1.8.2 release.



        Sample pre-push script: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample



        1.8.2 release notes talking about the new pre-push hook: https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt






        share|improve this answer














        Git got the pre-push hook in the 1.8.2 release.



        Sample pre-push script: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample



        1.8.2 release notes talking about the new pre-push hook: https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 14 '13 at 4:15

























        answered Feb 3 '13 at 13:17









        manojlds

        210k46367357




        210k46367357







        • 1




          Hey dude.. Thanks.. :)
          – Gaurav Agarwal
          Feb 6 '14 at 12:52






        • 1




          @manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
          – igrek
          Jun 19 '14 at 13:51










        • @igrek did you find a solution to the connection closing issue?
          – Mario Estrada
          Apr 27 '15 at 3:54










        • @MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
          – igrek
          Apr 28 '15 at 7:12







        • 4




          This needs to be the accepted answer.
          – The Dembinski
          Jan 16 '17 at 18:25












        • 1




          Hey dude.. Thanks.. :)
          – Gaurav Agarwal
          Feb 6 '14 at 12:52






        • 1




          @manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
          – igrek
          Jun 19 '14 at 13:51










        • @igrek did you find a solution to the connection closing issue?
          – Mario Estrada
          Apr 27 '15 at 3:54










        • @MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
          – igrek
          Apr 28 '15 at 7:12







        • 4




          This needs to be the accepted answer.
          – The Dembinski
          Jan 16 '17 at 18:25







        1




        1




        Hey dude.. Thanks.. :)
        – Gaurav Agarwal
        Feb 6 '14 at 12:52




        Hey dude.. Thanks.. :)
        – Gaurav Agarwal
        Feb 6 '14 at 12:52




        1




        1




        @manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
        – igrek
        Jun 19 '14 at 13:51




        @manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
        – igrek
        Jun 19 '14 at 13:51












        @igrek did you find a solution to the connection closing issue?
        – Mario Estrada
        Apr 27 '15 at 3:54




        @igrek did you find a solution to the connection closing issue?
        – Mario Estrada
        Apr 27 '15 at 3:54












        @MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
        – igrek
        Apr 28 '15 at 7:12





        @MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
        – igrek
        Apr 28 '15 at 7:12





        4




        4




        This needs to be the accepted answer.
        – The Dembinski
        Jan 16 '17 at 18:25




        This needs to be the accepted answer.
        – The Dembinski
        Jan 16 '17 at 18:25










        up vote
        19
        down vote














        Git got the pre-push hook in the 1.8.2 release.




        Pre-push hooks are what I needed along with pre-commit hooks. Apart from protecting a branch, they can also provide extra security combined with pre-commit hooks.



        And for an example on how to use (taken and adopted and enhanced from this nice entry)



        Simple example to login to vagrant, run tests and then push



        #!/bin/bash
        # Run the following command in the root of your project to install this pre-push hook:
        # cp git-hooks/pre-push .git/hooks/pre-push; chmod 700 .git/hooks/pre-push

        CMD="ssh vagrant@192.168.33.10 -i ~/.vagrant.d/insecure_private_key 'cd /vagrant/tests; /vagrant/vendor/bin/phpunit'"
        protected_branch='master'

        # Check if we actually have commits to push
        commits=`git log @u..`
        if [ -z "$commits" ]; then
        exit 0
        fi

        current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/(.*),1,')

        if [[ $current_branch = $protected_branch ]]; then
        eval $CMD
        RESULT=$?
        if [ $RESULT -ne 0 ]; then
        echo "failed $CMD"
        exit 1
        fi
        fi
        exit 0


        As you can see the example uses a protected branch, subject of the pre-push hook.






        share|improve this answer
























          up vote
          19
          down vote














          Git got the pre-push hook in the 1.8.2 release.




          Pre-push hooks are what I needed along with pre-commit hooks. Apart from protecting a branch, they can also provide extra security combined with pre-commit hooks.



          And for an example on how to use (taken and adopted and enhanced from this nice entry)



          Simple example to login to vagrant, run tests and then push



          #!/bin/bash
          # Run the following command in the root of your project to install this pre-push hook:
          # cp git-hooks/pre-push .git/hooks/pre-push; chmod 700 .git/hooks/pre-push

          CMD="ssh vagrant@192.168.33.10 -i ~/.vagrant.d/insecure_private_key 'cd /vagrant/tests; /vagrant/vendor/bin/phpunit'"
          protected_branch='master'

          # Check if we actually have commits to push
          commits=`git log @u..`
          if [ -z "$commits" ]; then
          exit 0
          fi

          current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/(.*),1,')

          if [[ $current_branch = $protected_branch ]]; then
          eval $CMD
          RESULT=$?
          if [ $RESULT -ne 0 ]; then
          echo "failed $CMD"
          exit 1
          fi
          fi
          exit 0


          As you can see the example uses a protected branch, subject of the pre-push hook.






          share|improve this answer






















            up vote
            19
            down vote










            up vote
            19
            down vote










            Git got the pre-push hook in the 1.8.2 release.




            Pre-push hooks are what I needed along with pre-commit hooks. Apart from protecting a branch, they can also provide extra security combined with pre-commit hooks.



            And for an example on how to use (taken and adopted and enhanced from this nice entry)



            Simple example to login to vagrant, run tests and then push



            #!/bin/bash
            # Run the following command in the root of your project to install this pre-push hook:
            # cp git-hooks/pre-push .git/hooks/pre-push; chmod 700 .git/hooks/pre-push

            CMD="ssh vagrant@192.168.33.10 -i ~/.vagrant.d/insecure_private_key 'cd /vagrant/tests; /vagrant/vendor/bin/phpunit'"
            protected_branch='master'

            # Check if we actually have commits to push
            commits=`git log @u..`
            if [ -z "$commits" ]; then
            exit 0
            fi

            current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/(.*),1,')

            if [[ $current_branch = $protected_branch ]]; then
            eval $CMD
            RESULT=$?
            if [ $RESULT -ne 0 ]; then
            echo "failed $CMD"
            exit 1
            fi
            fi
            exit 0


            As you can see the example uses a protected branch, subject of the pre-push hook.






            share|improve this answer













            Git got the pre-push hook in the 1.8.2 release.




            Pre-push hooks are what I needed along with pre-commit hooks. Apart from protecting a branch, they can also provide extra security combined with pre-commit hooks.



            And for an example on how to use (taken and adopted and enhanced from this nice entry)



            Simple example to login to vagrant, run tests and then push



            #!/bin/bash
            # Run the following command in the root of your project to install this pre-push hook:
            # cp git-hooks/pre-push .git/hooks/pre-push; chmod 700 .git/hooks/pre-push

            CMD="ssh vagrant@192.168.33.10 -i ~/.vagrant.d/insecure_private_key 'cd /vagrant/tests; /vagrant/vendor/bin/phpunit'"
            protected_branch='master'

            # Check if we actually have commits to push
            commits=`git log @u..`
            if [ -z "$commits" ]; then
            exit 0
            fi

            current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/(.*),1,')

            if [[ $current_branch = $protected_branch ]]; then
            eval $CMD
            RESULT=$?
            if [ $RESULT -ne 0 ]; then
            echo "failed $CMD"
            exit 1
            fi
            fi
            exit 0


            As you can see the example uses a protected branch, subject of the pre-push hook.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jan 29 '14 at 14:57









            Jimmy Kane

            9,72465281




            9,72465281




















                up vote
                13
                down vote













                If you are using the command line, the easiest way to do this is to write a push script that runs your unit tests and, if they succeed, completes the push.



                Edit



                As of git 1.8.2 this answer is outdated. See manojlds's answer above.






                share|improve this answer






















                • do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
                  – sheepwalker
                  Nov 16 '10 at 16:22






                • 1




                  @sheepwalker: s/pull/push/, and use an alias to make it nice and short.
                  – Cascabel
                  Nov 16 '10 at 18:02










                • @sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
                  – kubi
                  Nov 16 '10 at 20:08















                up vote
                13
                down vote













                If you are using the command line, the easiest way to do this is to write a push script that runs your unit tests and, if they succeed, completes the push.



                Edit



                As of git 1.8.2 this answer is outdated. See manojlds's answer above.






                share|improve this answer






















                • do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
                  – sheepwalker
                  Nov 16 '10 at 16:22






                • 1




                  @sheepwalker: s/pull/push/, and use an alias to make it nice and short.
                  – Cascabel
                  Nov 16 '10 at 18:02










                • @sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
                  – kubi
                  Nov 16 '10 at 20:08













                up vote
                13
                down vote










                up vote
                13
                down vote









                If you are using the command line, the easiest way to do this is to write a push script that runs your unit tests and, if they succeed, completes the push.



                Edit



                As of git 1.8.2 this answer is outdated. See manojlds's answer above.






                share|improve this answer














                If you are using the command line, the easiest way to do this is to write a push script that runs your unit tests and, if they succeed, completes the push.



                Edit



                As of git 1.8.2 this answer is outdated. See manojlds's answer above.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Jan 8 '14 at 17:23

























                answered Nov 16 '10 at 16:10









                kubi

                33.2k1886114




                33.2k1886114











                • do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
                  – sheepwalker
                  Nov 16 '10 at 16:22






                • 1




                  @sheepwalker: s/pull/push/, and use an alias to make it nice and short.
                  – Cascabel
                  Nov 16 '10 at 18:02










                • @sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
                  – kubi
                  Nov 16 '10 at 20:08

















                • do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
                  – sheepwalker
                  Nov 16 '10 at 16:22






                • 1




                  @sheepwalker: s/pull/push/, and use an alias to make it nice and short.
                  – Cascabel
                  Nov 16 '10 at 18:02










                • @sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
                  – kubi
                  Nov 16 '10 at 20:08
















                do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
                – sheepwalker
                Nov 16 '10 at 16:22




                do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
                – sheepwalker
                Nov 16 '10 at 16:22




                1




                1




                @sheepwalker: s/pull/push/, and use an alias to make it nice and short.
                – Cascabel
                Nov 16 '10 at 18:02




                @sheepwalker: s/pull/push/, and use an alias to make it nice and short.
                – Cascabel
                Nov 16 '10 at 18:02












                @sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
                – kubi
                Nov 16 '10 at 20:08





                @sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
                – kubi
                Nov 16 '10 at 20:08











                up vote
                7
                down vote













                There isn't a hook for it, because a push isn't an operation that modifies your repository.



                You can do the checks on the receiving side though, in the post-receive hook. That is where you would usually reject an incoming push. Running unit tests might be a little intensive to do in a hook, but that's up to you.






                share|improve this answer
























                  up vote
                  7
                  down vote













                  There isn't a hook for it, because a push isn't an operation that modifies your repository.



                  You can do the checks on the receiving side though, in the post-receive hook. That is where you would usually reject an incoming push. Running unit tests might be a little intensive to do in a hook, but that's up to you.






                  share|improve this answer






















                    up vote
                    7
                    down vote










                    up vote
                    7
                    down vote









                    There isn't a hook for it, because a push isn't an operation that modifies your repository.



                    You can do the checks on the receiving side though, in the post-receive hook. That is where you would usually reject an incoming push. Running unit tests might be a little intensive to do in a hook, but that's up to you.






                    share|improve this answer












                    There isn't a hook for it, because a push isn't an operation that modifies your repository.



                    You can do the checks on the receiving side though, in the post-receive hook. That is where you would usually reject an incoming push. Running unit tests might be a little intensive to do in a hook, but that's up to you.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Nov 16 '10 at 16:37









                    Jakob Borg

                    16.6k54246




                    16.6k54246




















                        up vote
                        5
                        down vote













                        For the record, there is a patch to Git 1.6 that adds a pre-push hook. I don't know whether it works against 1.7.



                        Rather than mess with that, you could run push script like @kubi recommended. You could also make it a Rake task instead so it's in your repo. ruby-git could help with this. If you check the target repo, you could run tests only when pushing to the production repo.



                        Finally, you could run your tests in your pre-commit hook but check for what branch is being committed to. Then you could have a, say, a production branch that requires all tests pass before accepting a commit but your master doesn't care. limerick_rake may be useful in that scenario.






                        share|improve this answer






















                        • thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
                          – sheepwalker
                          Mar 1 '11 at 15:56














                        up vote
                        5
                        down vote













                        For the record, there is a patch to Git 1.6 that adds a pre-push hook. I don't know whether it works against 1.7.



                        Rather than mess with that, you could run push script like @kubi recommended. You could also make it a Rake task instead so it's in your repo. ruby-git could help with this. If you check the target repo, you could run tests only when pushing to the production repo.



                        Finally, you could run your tests in your pre-commit hook but check for what branch is being committed to. Then you could have a, say, a production branch that requires all tests pass before accepting a commit but your master doesn't care. limerick_rake may be useful in that scenario.






                        share|improve this answer






















                        • thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
                          – sheepwalker
                          Mar 1 '11 at 15:56












                        up vote
                        5
                        down vote










                        up vote
                        5
                        down vote









                        For the record, there is a patch to Git 1.6 that adds a pre-push hook. I don't know whether it works against 1.7.



                        Rather than mess with that, you could run push script like @kubi recommended. You could also make it a Rake task instead so it's in your repo. ruby-git could help with this. If you check the target repo, you could run tests only when pushing to the production repo.



                        Finally, you could run your tests in your pre-commit hook but check for what branch is being committed to. Then you could have a, say, a production branch that requires all tests pass before accepting a commit but your master doesn't care. limerick_rake may be useful in that scenario.






                        share|improve this answer














                        For the record, there is a patch to Git 1.6 that adds a pre-push hook. I don't know whether it works against 1.7.



                        Rather than mess with that, you could run push script like @kubi recommended. You could also make it a Rake task instead so it's in your repo. ruby-git could help with this. If you check the target repo, you could run tests only when pushing to the production repo.



                        Finally, you could run your tests in your pre-commit hook but check for what branch is being committed to. Then you could have a, say, a production branch that requires all tests pass before accepting a commit but your master doesn't care. limerick_rake may be useful in that scenario.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Nov 11 at 8:27









                        jchevali

                        1268




                        1268










                        answered Feb 17 '11 at 16:55









                        Turadg

                        5,96024144




                        5,96024144











                        • thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
                          – sheepwalker
                          Mar 1 '11 at 15:56
















                        • thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
                          – sheepwalker
                          Mar 1 '11 at 15:56















                        thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
                        – sheepwalker
                        Mar 1 '11 at 15:56




                        thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
                        – sheepwalker
                        Mar 1 '11 at 15:56










                        up vote
                        0
                        down vote













                        The script linked by the highly-voted answer shows the parameters etc to the pre-push hook ($1 is remote name, $2 URL) and how to access the commits (lines read from stdin have structure <local ref> <local sha1> <remote ref> <remote sha1>)



                        #!/bin/sh

                        # An example hook script to verify what is about to be pushed. Called by "git
                        # push" after it has checked the remote status, but before anything has been
                        # pushed. If this script exits with a non-zero status nothing will be pushed.
                        #
                        # This hook is called with the following parameters:
                        #
                        # $1 -- Name of the remote to which the push is being done
                        # $2 -- URL to which the push is being done
                        #
                        # If pushing without using a named remote those arguments will be equal.
                        #
                        # Information about the commits which are being pushed is supplied as lines to
                        # the standard input in the form:
                        #
                        # <local ref> <local sha1> <remote ref> <remote sha1>
                        #
                        # This sample shows how to prevent push of commits where the log message starts
                        # with "WIP" (work in progress).

                        remote="$1"
                        url="$2"

                        z40=0000000000000000000000000000000000000000

                        while read local_ref local_sha remote_ref remote_sha
                        do
                        if [ "$local_sha" = $z40 ]
                        then
                        # Handle delete
                        :
                        else
                        if [ "$remote_sha" = $z40 ]
                        then
                        # New branch, examine all commits
                        range="$local_sha"
                        else
                        # Update to existing branch, examine new commits
                        range="$remote_sha..$local_sha"
                        fi

                        # Check for WIP commit
                        commit=`git rev-list -n 1 --grep '^WIP' "$range"`
                        if [ -n "$commit" ]
                        then
                        echo >&2 "Found WIP commit in $local_ref, not pushing"
                        exit 1
                        fi
                        fi
                        done

                        exit 0





                        share|improve this answer
























                          up vote
                          0
                          down vote













                          The script linked by the highly-voted answer shows the parameters etc to the pre-push hook ($1 is remote name, $2 URL) and how to access the commits (lines read from stdin have structure <local ref> <local sha1> <remote ref> <remote sha1>)



                          #!/bin/sh

                          # An example hook script to verify what is about to be pushed. Called by "git
                          # push" after it has checked the remote status, but before anything has been
                          # pushed. If this script exits with a non-zero status nothing will be pushed.
                          #
                          # This hook is called with the following parameters:
                          #
                          # $1 -- Name of the remote to which the push is being done
                          # $2 -- URL to which the push is being done
                          #
                          # If pushing without using a named remote those arguments will be equal.
                          #
                          # Information about the commits which are being pushed is supplied as lines to
                          # the standard input in the form:
                          #
                          # <local ref> <local sha1> <remote ref> <remote sha1>
                          #
                          # This sample shows how to prevent push of commits where the log message starts
                          # with "WIP" (work in progress).

                          remote="$1"
                          url="$2"

                          z40=0000000000000000000000000000000000000000

                          while read local_ref local_sha remote_ref remote_sha
                          do
                          if [ "$local_sha" = $z40 ]
                          then
                          # Handle delete
                          :
                          else
                          if [ "$remote_sha" = $z40 ]
                          then
                          # New branch, examine all commits
                          range="$local_sha"
                          else
                          # Update to existing branch, examine new commits
                          range="$remote_sha..$local_sha"
                          fi

                          # Check for WIP commit
                          commit=`git rev-list -n 1 --grep '^WIP' "$range"`
                          if [ -n "$commit" ]
                          then
                          echo >&2 "Found WIP commit in $local_ref, not pushing"
                          exit 1
                          fi
                          fi
                          done

                          exit 0





                          share|improve this answer






















                            up vote
                            0
                            down vote










                            up vote
                            0
                            down vote









                            The script linked by the highly-voted answer shows the parameters etc to the pre-push hook ($1 is remote name, $2 URL) and how to access the commits (lines read from stdin have structure <local ref> <local sha1> <remote ref> <remote sha1>)



                            #!/bin/sh

                            # An example hook script to verify what is about to be pushed. Called by "git
                            # push" after it has checked the remote status, but before anything has been
                            # pushed. If this script exits with a non-zero status nothing will be pushed.
                            #
                            # This hook is called with the following parameters:
                            #
                            # $1 -- Name of the remote to which the push is being done
                            # $2 -- URL to which the push is being done
                            #
                            # If pushing without using a named remote those arguments will be equal.
                            #
                            # Information about the commits which are being pushed is supplied as lines to
                            # the standard input in the form:
                            #
                            # <local ref> <local sha1> <remote ref> <remote sha1>
                            #
                            # This sample shows how to prevent push of commits where the log message starts
                            # with "WIP" (work in progress).

                            remote="$1"
                            url="$2"

                            z40=0000000000000000000000000000000000000000

                            while read local_ref local_sha remote_ref remote_sha
                            do
                            if [ "$local_sha" = $z40 ]
                            then
                            # Handle delete
                            :
                            else
                            if [ "$remote_sha" = $z40 ]
                            then
                            # New branch, examine all commits
                            range="$local_sha"
                            else
                            # Update to existing branch, examine new commits
                            range="$remote_sha..$local_sha"
                            fi

                            # Check for WIP commit
                            commit=`git rev-list -n 1 --grep '^WIP' "$range"`
                            if [ -n "$commit" ]
                            then
                            echo >&2 "Found WIP commit in $local_ref, not pushing"
                            exit 1
                            fi
                            fi
                            done

                            exit 0





                            share|improve this answer












                            The script linked by the highly-voted answer shows the parameters etc to the pre-push hook ($1 is remote name, $2 URL) and how to access the commits (lines read from stdin have structure <local ref> <local sha1> <remote ref> <remote sha1>)



                            #!/bin/sh

                            # An example hook script to verify what is about to be pushed. Called by "git
                            # push" after it has checked the remote status, but before anything has been
                            # pushed. If this script exits with a non-zero status nothing will be pushed.
                            #
                            # This hook is called with the following parameters:
                            #
                            # $1 -- Name of the remote to which the push is being done
                            # $2 -- URL to which the push is being done
                            #
                            # If pushing without using a named remote those arguments will be equal.
                            #
                            # Information about the commits which are being pushed is supplied as lines to
                            # the standard input in the form:
                            #
                            # <local ref> <local sha1> <remote ref> <remote sha1>
                            #
                            # This sample shows how to prevent push of commits where the log message starts
                            # with "WIP" (work in progress).

                            remote="$1"
                            url="$2"

                            z40=0000000000000000000000000000000000000000

                            while read local_ref local_sha remote_ref remote_sha
                            do
                            if [ "$local_sha" = $z40 ]
                            then
                            # Handle delete
                            :
                            else
                            if [ "$remote_sha" = $z40 ]
                            then
                            # New branch, examine all commits
                            range="$local_sha"
                            else
                            # Update to existing branch, examine new commits
                            range="$remote_sha..$local_sha"
                            fi

                            # Check for WIP commit
                            commit=`git rev-list -n 1 --grep '^WIP' "$range"`
                            if [ -n "$commit" ]
                            then
                            echo >&2 "Found WIP commit in $local_ref, not pushing"
                            exit 1
                            fi
                            fi
                            done

                            exit 0






                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Oct 1 '17 at 12:39









                            serv-inc

                            12.8k56484




                            12.8k56484



























                                draft saved

                                draft discarded
















































                                Thanks for contributing an answer to Stack Overflow!


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid


                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.

                                To learn more, see our tips on writing great answers.





                                Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                                Please pay close attention to the following guidance:


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid


                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.

                                To learn more, see our tips on writing great answers.




                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function ()
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f4196148%2fgit-pre-push-hooks%23new-answer', 'question_page');

                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown







                                Popular posts from this blog

                                Top Tejano songwriter Luis Silva dead of heart attack at 64

                                ReactJS Fetched API data displays live - need Data displayed static

                                Evgeni Malkin