On 11/04/2011 4:12 pm, Konstantin Khomoutov 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.
You're quite right -- slip on my part there.
For even more clarity:
When serving a repo over HTTP, the repo that your HTTP server points to
should be 'bare' -- that is, it was creating using 'git init --bare',
meaning it consists solely of the contents of what would normally be in
a .git directory, and therefore has no working copy (no checked-out files).
By convention, your bare repo's folder name ends with '.git' (eg
You then keep another copy of your repo elsewhere in your workspace, and
commit to that. When you're ready to share your changes (which may
consist of more than one commit), you push them to the bare repo.
The post-update hook runs when the repository is pushed to, and so will
run (providing it's properly configured) when you push your changes to
the bare repo.
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 email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at