{"thread":{"id":"16305","subject":"post-update hook","startedAt":"2008-11-13T15:53:28Z","lastAt":"2008-11-13T22:06:53Z","messageCount":4,"participants":["Jeremy Ramer","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"95692","messageId":"b9fd99020811130753o13c5aa0cj79126a502d449cde@mail.gmail.com","threadId":"16305","inReplyTo":null,"subject":"post-update hook","fromName":"Jeremy Ramer","fromEmail":"jdramer@gmail.com","sentAt":"2008-11-13T15:53:28Z","receivedAt":"2008-11-13T15:53:28Z","isPatch":false,"sender":{"key":"jdramer@gmail.com","avatar":null},"body":"I have a set up where I have a local git repo (local1) that I make\nchanges to and two public repos (remote1, remote2) that hold the\ncurrent state of the repo for other applications to access. So my\nplan is to make the change is local1, then\ngit commit\ngit push remote1 master\ngit push remote2 master\n\nHowever, the remotes currently have master checked out so though the\nrepo gets updated the working directory does not. I tried editting\nthe post-update hook as follows\n\n#!/bin/sh\necho Update changes...\ngit checkout master .\n\nbut it does not seem to make any difference. Am I missing something\nin the way post-update works? It would be really nice to get this\nworking so I don't have to log into each remote and do a pull. local1\nis running git version 1.6.0.2. remotes are running git version 1.5.6.\n\nThanks!\nJeremy\n"},{"id":"95700","messageId":"7v7i77h7tp.fsf@gitster.siamese.dyndns.org","threadId":"16305","inReplyTo":"b9fd99020811130753o13c5aa0cj79126a502d449cde@mail.gmail.com","subject":"Re: post-update hook","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-13T17:08:50Z","receivedAt":"2008-11-13T17:08:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jeremy Ramer\" writes:\n\n> ... I tried editting\n> the post-update hook as follows\n>\n> #!/bin/sh\n> echo Update changes...\n> git checkout master .\n>\n> but it does not seem to make any difference.\n\nBy above do you mean you do not even see \"Update changes...\", or do you\nmean you do see that message but \"checkout\" does not seem to do anything?\n\nI notice that you said you \"tried _editing_\"; did you also enable it?\n\nIf you enabled it, you would see \"Update changes...\" but notice that \"git\ncheckout master\" reports modifications. Try adding \"-f\" between \"checkout\"\nand \"master\".\n\n> ... Am I missing something\n> in the way post-update works?\n\nThat, or in the way \"checkout\" works.\n\nBy the way, this is one reason why pushing directly into the checked out\nbranch of a non-bare repository is not optimal. A recommended practice is\nto make the automation pretend as if you did a pull from the remote,\n\n> ... It would be really nice to get this\n> working so I don't have to log into each remote and do a pull.\n\nwithout actually having to log into each remote and run \"pull\" there.\n\n * Realize that if you did go to the remote and run \"pull\", then the\n change from the local machine is copied (via the underlying \"fetch\"\n that is run by \"pull\") in \"remotes/origin/master\", not to the branch\n \"master\". And then the result is merged.\n\n IOW, \n\n\tremote$ git pull\n\n when fully spelled out, is:\n\n\tremote$ git fetch local1 master:remotes/origin/master\n remote$ git merge remotes/origin/master\n\n That is, \"master\" branch tip from local1 goes to remote branch\n \"origin/master\" at remote1, and it is merged to whatever is checked\n out.\n\n * Arrange that if you push from local1 to remote1, the above\n automatically happens, in post-update hook. So\n\n (1) Do not push into 'master'; IOW, do not:\n\n\tlocal1$ git push remote1 master:master ;# BAD\n\n Instead, push into the remotes/origin/master, to mimic _as if you\n fetched in the opposite direction_, like so:\n\n\tlocal1$ git push remote1 master:refs/remotes/origin/master\n\n Notice that this corresponds to what happens in the \"git fetch\"\n phase if you pulled in the reverse. So all the hook needs to do is\n to merge.\n\n (2) Arrange post-update on the remote end to run the merge, when a push\n came to \"origin/master\", something like:\n\n\t#!/bin/sh\n case \" $* \" in\n *' refs/remotes/origin/master '*)\n \tcd .. ;# you would be in .git -- go to the root of tree\n git merge refs/remotes/origin/master\n ;;\n\tesac\n\n I didn't test this, though...\n\nThe advantage of doing it this way is that you can configure it so that it\ndoes not matter in which direction you actually work. When you _do_ have\nto go to the remote side to get the changes from local (perhaps on some\nemergency that keeps you at remote), you can do a \"git pull local\" and you\ncan expect that the exact same thing as what your post-update script\nordinarily does happens.\n"},{"id":"95708","messageId":"b9fd99020811131048p741cd9aqdcdf4cf410830915@mail.gmail.com","threadId":"16305","inReplyTo":"7v7i77h7tp.fsf@gitster.siamese.dyndns.org","subject":"Re: post-update hook","fromName":"Jeremy Ramer","fromEmail":"jdramer@gmail.com","sentAt":"2008-11-13T18:48:52Z","receivedAt":"2008-11-13T18:48:52Z","isPatch":false,"sender":{"key":"jdramer@gmail.com","avatar":null},"body":"On Thu, Nov 13, 2008 at 10:08 AM, Junio C Hamano wrote:\n> \"Jeremy Ramer\" writes:\n>\n>> ... I tried editting\n>> the post-update hook as follows\n>>\n>> #!/bin/sh\n>> echo Update changes...\n>> git checkout master .\n>>\n>> but it does not seem to make any difference.\n>\n> By above do you mean you do not even see \"Update changes...\", or do you\n> mean you do see that message but \"checkout\" does not seem to do anything?\n>\n> I notice that you said you \"tried _editing_\"; did you also enable it?\n>\n> If you enabled it, you would see \"Update changes...\" but notice that \"git\n> checkout master\" reports modifications. Try adding \"-f\" between \"checkout\"\n> and \"master\".\n\nI did see the \"Update changes...\" I enabled the post-update script. Sorry for\nnot being clear about that.\n\n>> ... Am I missing something\n>> in the way post-update works?\n>\n> That, or in the way \"checkout\" works.\n>\n> By the way, this is one reason why pushing directly into the checked out\n> branch of a non-bare repository is not optimal. A recommended practice is\n> to make the automation pretend as if you did a pull from the remote,\n>\n>> ... It would be really nice to get this\n>> working so I don't have to log into each remote and do a pull.\n>\n> without actually having to log into each remote and run \"pull\" there.\n>\n> * Realize that if you did go to the remote and run \"pull\", then the\n> change from the local machine is copied (via the underlying \"fetch\"\n> that is run by \"pull\") in \"remotes/origin/master\", not to the branch\n> \"master\". And then the result is merged.\n>\n> IOW,\n>\n> remote$ git pull\n>\n> when fully spelled out, is:\n>\n> remote$ git fetch local1 master:remotes/origin/master\n> remote$ git merge remotes/origin/master\n>\n> That is, \"master\" branch tip from local1 goes to remote branch\n> \"origin/master\" at remote1, and it is merged to whatever is checked\n> out.\n\nI thought I understood this process but I guess I didn't think it through\nfully. What you are suggesting makes sense.\n\n>\n> * Arrange that if you push from local1 to remote1, the above\n> automatically happens, in post-update hook. So\n>\n> (1) Do not push into 'master'; IOW, do not:\n>\n> local1$ git push remote1 master:master ;# BAD\n>\n> Instead, push into the remotes/origin/master, to mimic _as if you\n> fetched in the opposite direction_, like so:\n>\n> local1$ git push remote1 master:refs/remotes/origin/master\n>\n> Notice that this corresponds to what happens in the \"git fetch\"\n> phase if you pulled in the reverse. So all the hook needs to do is\n> to merge.\n>\n> (2) Arrange post-update on the remote end to run the merge, when a push\n> came to \"origin/master\", something like:\n>\n> #!/bin/sh\n> case \" $* \" in\n> *' refs/remotes/origin/master '*)\n> cd .. ;# you would be in .git -- go to the root of tree\n> git merge refs/remotes/origin/master\n> ;;\n> esac\n>\n> I didn't test this, though...\n\nI had to make one change to this example to get it to work. I'll put\nit here for completeness\n\n#!/bin/sh\ncase \"$*\" in\n\"refs/remotes/origin/master\")\n cd ..\n GIT_DIR=\".git\"\n git merge refs/remotes/origin/master\n ;;\nesac\n\n>\n> The advantage of doing it this way is that you can configure it so that it\n> does not matter in which direction you actually work. When you _do_ have\n> to go to the remote side to get the changes from local (perhaps on some\n> emergency that keeps you at remote), you can do a \"git pull local\" and you\n> can expect that the exact same thing as what your post-update script\n> ordinarily does happens.\n>\n\nThanks for the quick response!\n"},{"id":"95732","messageId":"7vskpvffgi.fsf@gitster.siamese.dyndns.org","threadId":"16305","inReplyTo":"b9fd99020811131048p741cd9aqdcdf4cf410830915@mail.gmail.com","subject":"Re: post-update hook","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-13T22:06:53Z","receivedAt":"2008-11-13T22:06:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jeremy Ramer\" writes:\n\n> I had to make one change to this example to get it to work. I'll put\n> it here for completeness\n>\n> #!/bin/sh\n> case \"$*\" in\n> \"refs/remotes/origin/master\")\n> cd ..\n> GIT_DIR=\".git\"\n> git merge refs/remotes/origin/master\n> ;;\n> esac\n\nYeah, thanks for correction. My bad not resetting GIT_DIR.\n\nBy the way, I _did_ write these seemingly extra spaces around $* and the\nrefname on purpose.\n"}]}