On Tue, Apr 12, 2011 at 10:56:44AM +0530, Mohith Thimmaiah wrote:

> > On Mon, 11 Apr 2011 13:43:25 +0100
> > Antony Male <antony.m...@gmail.com> wrote:
> > [...]
> > > When you clone (or fetch) a repository over the git protocol, a
> > > program on your computer (git-fetch-pack) and a similar one on the
> > > server (git-upload-pack) coordinate to figure out exactly what
> > > commits (roughly speaking) needs to be sent to you.
> > >
> > > HTTP, however, is a "dumb" protocol, meaning that this approach
> > > cannot be taken.
> > > Therefore, some auxiliary files need to be present on the server, to
> > > allow your client to figure out what commits it needs to request.
> > >
> > > These files aren't generated by default -- you need to run git
> > > update-server-info after every commit in order to generate them.
> > Being pedantic here, for clarity: this is needed to be run after every
> > push, not commit--a push can send a whole lot of commits in one go
> > which is a common pattern for a DVCS.
> Prefer to use the soln suggested by Antony
> [1]: http://progit.org/book/ch4-1.html#the_https_protocol
> [2]: http://progit.org/book/ch4-5.html
> This is onetime setup - no need to run
> after every push. Just so others who follow can see this
Well, we both presented the same solution, just pointed to different
docs (Antony pointed to a book and I pointed to the manual page).
Hence my remark refers to how that hook runs--once per push which may
bring arbitrary number of commits (and even update several refs (read:
branches and tags) in one go using those commits).

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to