On Thu, Nov 13, 2008 at 10:08 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> "Jeremy Ramer" <jdramer@xxxxxxxxx> 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!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
