Re: post-update hook

["Jeremy Ramer" <jdramer@gmail.com>]

On Thu, Nov 13, 2008 at 10:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Jeremy Ramer" <jdramer@gmail.com> writes:
>
>> ...  I tried editting
>> the post-update hook as follows
>>
>> #!/bin/sh
>> echo Update changes...
>> git checkout master .
>>
>> but it does not seem to make any difference.
>
> By above do you mean you do not even see "Update changes...", or do you
> mean you do see that message but "checkout"  does not seem to do anything?
>
> I notice that you said you "tried _editing_"; did you also enable it?
>
> If you enabled it, you would see "Update changes..." but notice that "git
> checkout master" reports modifications.  Try adding "-f" between "checkout"
> and "master".

I did see the "Update changes..."  I enabled the post-update script. Sorry for
not being clear about that.

>> ...  Am I missing something
>> in the way post-update works?
>
> That, or in the way "checkout" works.
>
> By the way, this is one reason why pushing directly into the checked out
> branch of a non-bare repository is not optimal.  A recommended practice is
> to make the automation pretend as if you did a pull from the remote,
>
>> ...  It would be really nice to get this
>> working so I don't have to log into each remote and do a pull.
>
> without actually having to log into each remote and run "pull" there.
>
>  * Realize that if you did go to the remote and run "pull", then the
>   change from the local machine is copied (via the underlying "fetch"
>   that is run by "pull") in "remotes/origin/master", not to the branch
>   "master".  And then the result is merged.
>
>   IOW,
>
>        remote$ git pull
>
>   when fully spelled out, is:
>
>        remote$ git fetch local1 master:remotes/origin/master
>        remote$ git merge remotes/origin/master
>
>   That is, "master" branch tip from local1 goes to remote branch
>   "origin/master" at remote1, and it is merged to whatever is checked
>   out.

I thought I understood this process but I guess I didn't think it through
fully. What you are suggesting makes sense.

>
>  * Arrange that if you push from local1 to remote1, the above
>   automatically happens, in post-update hook.  So
>
>   (1) Do not push into 'master'; IOW, do not:
>
>        local1$ git push remote1 master:master ;# BAD
>
>       Instead, push into the remotes/origin/master, to mimic _as if you
>       fetched in the opposite direction_, like so:
>
>        local1$ git push remote1 master:refs/remotes/origin/master
>
>       Notice that this corresponds to what happens in the "git fetch"
>       phase if you pulled in the reverse.  So all the hook needs to do is
>       to merge.
>
>   (2) Arrange post-update on the remote end to run the merge, when a push
>       came to "origin/master", something like:
>
>        #!/bin/sh
>        case " $* " in
>        *' refs/remotes/origin/master '*)
>                cd .. ;# you would be in .git -- go to the root of tree
>                git merge refs/remotes/origin/master
>                ;;
>        esac
>
>        I didn't test this, though...

I had to make one change to this example to get it to work.  I'll put
it here for completeness

#!/bin/sh
case "$*" in
"refs/remotes/origin/master")
    cd ..
    GIT_DIR=".git"
    git merge refs/remotes/origin/master
    ;;
esac

>
> The advantage of doing it this way is that you can configure it so that it
> does not matter in which direction you actually work.  When you _do_ have
> to go to the remote side to get the changes from local (perhaps on some
> emergency that keeps you at remote), you can do a "git pull local" and you
> can expect that the exact same thing as what your post-update script
> ordinarily does happens.
>

Thanks for the quick response!