kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Andreas Ericsson	8d63013291	Server-side support for user-relative paths. This patch basically just removes the redundant code from {receive,upload}-pack.c in favour of the library code in path.c. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	d8a1deecc6	Refuse to create funny refs in clone-pack, git-fetch and receive-pack. Using git-check-ref-format, make sure we do not create refs with funny names when cloning from elsewhere (clone-pack), fast forwarding local heads (git-fetch), or somebody pushes into us (receive-pack). Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	2c04662d89	Revert "Replace zero-length array decls with []." This reverts `6c5f9baa3b` commit, whose change breaks gcc-2.95. Not that I ignore portability to compilers that are properly C99, but keeping compilation with GCC working is more important, at least for now. We would probably end up declaring with "name[1]" and teach the allocator to subtract one if we really aimed for portability, but that is left for later rounds. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Jason Riedy	e72a7d45dc	Replace unsetenv() and setenv() with older putenv(). Solaris 8 doesn't have the newer unsetenv() and setenv() functions, so replace them with putenv(). The one use of unsetenv() in fsck-cache.c now sets GIT_ALTERNATE_OBJECT_ DIRECTORIES to the empty string. Every place that var is used, NULLs are also replaced with empty strings, so it's ok. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>	20 years ago
Jason Riedy	6c5f9baa3b	Replace zero-length array decls with []. C99 denotes variable-sized members with [], not [0]. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>	20 years ago
Junio C Hamano	29f3b3de99	Make sure leading directories exist when pushing refs. 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>	20 years ago
Junio C Hamano	19614330dd	receive-pack hooks updates. 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>	20 years ago
A Large Angry SCM	c742b81397	[PATCH] Fix warning about non-void return in a void function. Signed-off-by: A Large Angry SCM <gitzilla@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Josef Weidendorfer	b1bf95bba2	[PATCH] Added hook in git-receive-pack 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>	20 years ago
Junio C Hamano	8f3f9b09dc	[PATCH] Add update-server-info. 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>	20 years ago
Linus Torvalds	113b94751d	Make "upload-pack" match git-fetch-pack usage Do the default "try xyz.git xyz fails" thing for the directory we get passed in.	20 years ago
Junio C Hamano	f312de018b	[PATCH] Let umask do its work upon filesystem object creation. 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>	20 years ago
Linus Torvalds	6da4016aea	Fix sparse warnings. Mainly making a lot of local functions and variables be marked "static", but there was a "zero as NULL" warning in there too.	20 years ago
Linus Torvalds	944d858969	Fix up "for_each_ref()" to be more usable, and use it in git-fsck-cache It needed to take the GIT_DIR information into account, something that the original receive-pack usage just never cared about.	20 years ago
Linus Torvalds	8a65ff7666	Generalize the "show each ref" code in receice-pack This turns it into a generic "do xyz for each ref" library function.	20 years ago
Linus Torvalds	d0efc8a71d	Do ref matching on the sender side rather than on receiver 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".	20 years ago
Linus Torvalds	f65fdf04a1	Add support for "forcing" a ref on the remote side 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.	20 years ago
Linus Torvalds	2eca23daf5	git-receive-pack: implement ref switch command handling 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.	20 years ago
Linus Torvalds	eb1af2df0b	git-receive-pack: start parsing ref update commands We don't act on them yet, but we parse them.	20 years ago
Linus Torvalds	7f8e982834	Slow but steady progress on git pack receive/send	20 years ago
Linus Torvalds	f3a3214e83	Make send/receive-pack be closer to doing something interesting	20 years ago
Linus Torvalds	575f497456	Add first cut at "git-receive-pack" 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.	20 years ago

22 Commits (9cebe90bc55c76638f5cb8132d9fbd2769e05e54)