It does not matter if the only refs you push are directly
underneath heads and tags, but we forgot to make sure we have
leading directories so pushing tags/v0.99/1 would not have
worked.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier one conflated update and post-update hooks for no
good reason. Correct that ugly hack. Now post-update hooks
will take the list of successfully updated refs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Just before updating a ref,
$GIT_DIR/hooks/update refname old-sha1 new-sha1
is called if executable. The hook can decline the ref to be
updated by exiting with a non-zero status, or allow it to be
updated by exiting with a zero status. The mechanism also
allows e.g sending of a mail with pushed commits on the remote
repository.
Documentation update with an example hook is included.
jc: The credits of the basic idea and initial implementation go
to Josef, but I ended up rewriting major parts of his patch, so
bugs are all mine. Also I changed the semantics for the hook
from his original version (which were post-update hook) so that
the hook can optionally decline to update the ref, and also can
be used to implement the overall cleanups. The latter was
primarily to implement a suggestion from Linus that calling
update-server-info should be made optional.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The git-update-server-info command prepares informational files
to help clients discover the contents of a repository, and pull
from it via a dumb transport protocols. Currently, the
following files are produced.
- The $repo/info/refs file lists the name of heads and tags
available in the $repo/refs/ directory, along with their
SHA1. This can be used by git-ls-remote command running on
the client side.
- The $repo/info/rev-cache file describes the commit ancestry
reachable from references in the $repo/refs/ directory. This
file is in an append-only binary format to make the server
side friendly to rsync mirroring scheme, and can be read by
git-show-rev-cache command.
- The $repo/objects/info/pack file lists the name of the packs
available, the interdependencies among them, and the head
commits and tags contained in them. Along with the other two
files, this is designed to help clients to make smart pull
decisions.
The git-receive-pack command is changed to invoke it at the end,
so just after a push to a public repository finishes via "git
push", the server info is automatically updated.
In addition, building of the rev-cache file can be done by a
standalone git-build-rev-cache command separately.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
IIRC our strategy was to let the users' umask take care of the
final mode bits. This patch fixes places that deviate from it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This makes the receiver always send a full list of valid refs, which
will allow us to do better packs, as well as handle creation of new
refs. Eventually. Right now we just moved the matching and enabled it.
So now you can do
git-send-pack host:path branch1 branch2
to only send branches "branch1" and "branch2".
A "old ref" of all zeroes is considered a "don't care" ref, and allows
us to say "write the new ref regardless of what the old ref contained
(or even if it existed at all)".
This allows (if git-send-pack were to do it) creating new refs, and
fixing up old ones.
After unpacking the object pack successfully, we go through the list of
refs, and verify that they still contain their expected values. Then we
replace them with the new ones.
It's not working yet, but it's at the point where I want to be able to
track my changes. The theory of operation is that this is the "remote"
side of a "git push". It can tell us what references the remote side
has, receives out reference update commands and a pack-file, and can
execute the unpacking command.
Junio C Hamano
A Large Angry SCM
Josef Weidendorfer
Linus Torvalds
Linus Torvalds