{"thread":{"id":"13068","subject":"Re: how to use two bare repositories?","startedAt":"2008-04-11T23:44:30Z","lastAt":"2008-04-12T00:55:46Z","messageCount":4,"participants":["Oliver Kullmann","Junio C Hamano","しらいしななこ"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"74162","messageId":"20080411234430.GQ29940@cs-wsok.swansea.ac.uk","threadId":"13068","inReplyTo":null,"subject":"Re: how to use two bare repositories?","fromName":"Oliver Kullmann","fromEmail":"o.kullmann@swansea.ac.uk","sentAt":"2008-04-11T23:44:30Z","receivedAt":"2008-04-11T23:44:30Z","isPatch":false,"sender":{"key":"o.kullmann@swansea.ac.uk","avatar":null},"body":"Sorry, by error I didn't post this message to the\nlist, but it might be interesting for somebody,\nso here the copy.\n\n----- Forwarded message from Oliver Kullmann <O.Kullmann@swansea.ac.uk> -----\n\nX-Original-To: csoliver@cs-svr1.swan.ac.uk\nDelivered-To: csoliver@cs-svr1.swan.ac.uk\nDate: Sat, 12 Apr 2008 00:40:38 +0100\nFrom: Oliver Kullmann <O.Kullmann@swansea.ac.uk>\nTo: Junio C Hamano <gitster@pobox.com>\nSubject: Re: how to use two bare repositories?\nIn-Reply-To: <7v7if4ouan.fsf@gitster.siamese.dyndns.org>\nUser-Agent: Mutt/1.5.9i\n\nOn Fri, Apr 11, 2008 at 04:17:52PM -0700, Junio C Hamano wrote:\n> Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:\n> \n> > Now I want to create another public repository B,\n> > from which anonymous pull is possible via http.\n> > So B should be another bare repository.\n> >\n> > The problem is now that it seems not to be possible\n> > to update B:\n> >\n> > 1. pulling from A is not possible since B is bare;\n> > 2. fetching from A seems to work, checking the content of\n> >    B via gitk seems to indicate that B has been updated\n> >  --- however pulling from B doesn't work\n> \n> The usual answer when you see a word \"http\" mentioned is...\n> \n> \thow are you arranging update-server-info to be run whenever B is\n> \tupdated?\n\nAha, I see: So first I fetch, and then I run update-server-info.\nJust tried it out, and it worked. Thanks!\n\n(By the way, since B is updated anyway only by my package-building\nscript, it's no problem to run update-server-info then (by the script).)\n\n----- End forwarded message -----\n"},{"id":"74166","messageId":"7vabk0nd6x.fsf@gitster.siamese.dyndns.org","threadId":"13068","inReplyTo":"20080411234430.GQ29940@cs-wsok.swansea.ac.uk","subject":"Re: how to use two bare repositories?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-12T00:12:38Z","receivedAt":"2008-04-12T00:12:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:\n\n>> > The problem is now that it seems not to be possible\n>> > to update B:\n>> >\n>> > 1. pulling from A is not possible since B is bare;\n>> > 2. fetching from A seems to work, checking the content of\n>> >    B via gitk seems to indicate that B has been updated\n>> >  --- however pulling from B doesn't work\n>> \n>> The usual answer when you see a word \"http\" mentioned is...\n>> \n>> \thow are you arranging update-server-info to be run whenever B is\n>> \tupdated?\n>\n> Aha, I see: So first I fetch, and then I run update-server-info.\n> Just tried it out, and it worked. Thanks!\n\nTypically, you would update a bare repository used for publishing by\npushing into it, and trigger update-server-info from the post-update hook.\n\nBut it is perfectly fine if you initiate a mirror-fetch from that\npublishing repository (in your case, \"B\"), and the caller to \"git fetch\"\ncan run update-server-info after fetching.\n\nAnd no, there is not a \"post-fetch\" hook, nor is there a need for one.\n"},{"id":"74167","messageId":"200804120042.m3C0gmWR004445@mi0.bluebottle.com","threadId":"13068","inReplyTo":"7vabk0nd6x.fsf@gitster.siamese.dyndns.org","subject":"Re: how to use two bare repositories?","fromName":"しらいしななこ","fromEmail":"nanako3@bluebottle.com","sentAt":"2008-04-12T00:42:05Z","receivedAt":"2008-04-12T00:42:05Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Typically, you would update a bare repository used for publishing by\n> pushing into it, and trigger update-server-info from the post-update hook.\n>\n> But it is perfectly fine if you initiate a mirror-fetch from that\n> publishing repository (in your case, \"B\"), and the caller to \"git fetch\"\n> can run update-server-info after fetching.\n>\n> And no, there is not a \"post-fetch\" hook, nor is there a need for one.\n\nCan you please explain why?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n\n----------------------------------------------------------------------\nFinally - A spam blocker that actually works.\nhttp://www.bluebottle.com/tag/4\n"},{"id":"74169","messageId":"7vbq4fnb71.fsf@gitster.siamese.dyndns.org","threadId":"13068","inReplyTo":"200804120042.m3C0gmWR004445@mi0.bluebottle.com","subject":"Re: how to use two bare repositories?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-12T00:55:46Z","receivedAt":"2008-04-12T00:55:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"しらいしななこ  <nanako3@bluebottle.com> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Typically, you would update a bare repository used for publishing by\n>> pushing into it, and trigger update-server-info from the post-update hook.\n>>\n>> But it is perfectly fine if you initiate a mirror-fetch from that\n>> publishing repository (in your case, \"B\"), and the caller to \"git fetch\"\n>> can run update-server-info after fetching.\n>>\n>> And no, there is not a \"post-fetch\" hook, nor is there a need for one.\n>\n> Can you please explain why?\n\nThere are five valid reasons you might want to have a hook to a git\ncommand/operation:\n\n (1) A hook that countermands the normal decision made by the underlying\n     command.  Examples of this class are the update hook and the\n     pre-commit hook.\n\n (2) A hook that operates on data generated after the command starts to\n     run.  The ability to munge the commit log message by the commit-msg\n     hook is an example.\n\n (3) A hook that operates on the remote end of the connection that you may\n     not otherwise have access to, other than over the git protocol.  An\n     example is the post-update hook that runs update-server-info.\n\n (4) A hook that runs under a lock that is acquired by the command for\n     mutual exclusion.  Currently there is no example, but if we allowed\n     the update hook to modify the commit that was pushed through\n     send-pack => receive-pack pair, which was discussed on the list a\n     while ago, it would be a good example of this.\n\n (5) A hook that is run differently depending on the outcome of the\n     command.  The post-merge hook conditionally run by git-pull is an\n     example of this (it is not even run if no merge takes place).\n     Another example is the post-checkout hook that gets information that\n     is otherwise harder to get (namely, if it was a branch checkout or\n     file checkout -- you can figure it out by examining the command line\n     but that already is part of the processing git-checkout does anyway,\n     so no need to force duplicating that code in the userland).\n\nYou cannot do an equivalent operation from outside the git command for the\nabove classes of operations.  You need hooks for them.\n\nOn the other hand, if you want to always cause an action before or after\nrunning a git opeation locally, you do not have to have a hook.  This is\ntrue even if the action you would do after running a git operation depends\non what happened (class (5) above) if the result is easily observable\nafter the fact.\n\nOf course there can be a very valid exception to the above policy.  If it\nis common enough so that the policy means effectively everybody has to\nreinvent the same wrapper.  But for this particular case I do not think\nthat is the case.\n"}]}