summaryrefslogtreecommitdiff
path: root/receive-pack.c
AgeCommit message (Collapse)AuthorFilesLines
2006-08-29Remove uneeded #includeLibravatar Johannes Schindelin1-1/+0
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23Convert memcpy(a,b,20) to hashcpy(a,b).Libravatar Shawn Pearce1-2/+2
This abstracts away the size of the hash values when copying them from memory location to memory location, much as the introduction of hashcmp abstracted away hash value comparsion. A few call sites were using char* rather than unsigned char* so I added the cast rather than open hashcpy to be void*. This is a reasonable tradeoff as most call sites already use unsigned char* and the existing hashcmp is also declared to be unsigned char*. [jc: Splitted the patch to "master" part, to be followed by a patch for merge-recursive.c which is not in "master" yet. Fixed the cast in the latter hunk to combine-diff.c which was wrong in the original. Also converted ones left-over in combine-diff.c, diff-lib.c and upload-pack.c ] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-15remove unnecessary initializationsLibravatar David Rientjes1-3/+3
[jc: I needed to hand merge the changes to the updated codebase, so the result needs to be checked.] Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05Const tightening.Libravatar Junio C Hamano1-4/+6
Mark Wooding noticed there was a type mismatch warning in git.c; this patch does things slightly differently (mostly tightening const) and was what I was holding onto, waiting for the setup-revisions change to be merged into the master branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-22Give no terminating LF to error() function.Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-13Exec git programs without using PATH.Libravatar Michal Ostrowski1-2/+2
The git suite may not be in PATH (and thus programs such as git-send-pack could not exec git-rev-list). Thus there is a need for logic that will locate these programs. Modifying PATH is not desirable as it result in behavior differing from the user's intentions, as we may end up prepending "/usr/bin" to PATH. - git C programs will use exec*_git_cmd() APIs to exec sub-commands. - exec*_git_cmd() will execute a git program by searching for it in the following directories: 1. --exec-path (as used by "git") 2. The GIT_EXEC_PATH environment variable. 3. $(gitexecdir) as set in Makefile (default value $(bindir)). - git wrapper will modify PATH as before to enable shell scripts to invoke "git-foo" commands. Ideally, shell scripts should use the git wrapper to become independent of PATH, and then modifying PATH will not be necessary. [jc: with minor updates after a brief review.] Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-08GIT 1.1.0Libravatar Junio C Hamano1-1/+1
2006-01-07[PATCH] Compilation: zero-length array declaration.Libravatar Junio C Hamano1-1/+1
ISO C99 (and GCC 3.x or later) lets you write a flexible array at the end of a structure, like this: struct frotz { int xyzzy; char nitfol[]; /* more */ }; GCC 2.95 and 2.96 let you to do this with "char nitfol[0]"; unfortunately this is not allowed by ISO C90. This declares such construct like this: struct frotz { int xyzzy; char nitfol[FLEX_ARRAY]; /* more */ }; and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and empty for others. If you are using a C90 C compiler, you should be able to override this with CFLAGS=-DFLEX_ARRAY=1 from the command line of "make". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-27send-pack/receive-pack: allow errors to be reported back to pusher.Libravatar Junio C Hamano1-32/+88
This updates the protocol between git-send-pack/git-receive-pack in a backward compatible way to allow failures at the receiving end to be propagated back to the sender. Most notably, versions of git-push before this could not notice if the update hook on the receiving end refused to update the ref for its own policy reasons. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21\n usage in stderr outputLibravatar Alex Riesen1-1/+1
fprintf and die sometimes have missing/excessive "\n" in their arguments, correct the strings where I think it would be appropriate. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-07Clean up file descriptors when calling hooks.Libravatar Daniel Barkalow1-1/+1
When calling post-update hook, don't leave stdin and stdout connected to the pushing connection. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Server-side support for user-relative paths.Libravatar Andreas Ericsson1-13/+4
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>
2005-10-15Refuse to create funny refs in clone-pack, git-fetch and receive-pack.Libravatar Junio C Hamano1-0/+4
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>
2005-08-29Revert "Replace zero-length array decls with []."Libravatar Junio C Hamano1-1/+1
This reverts 6c5f9baa3bc0d63e141e0afc23110205379905a4 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>
2005-08-23Replace unsetenv() and setenv() with older putenv().Libravatar Jason Riedy1-1/+1
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>
2005-08-23Replace zero-length array decls with [].Libravatar Jason Riedy1-1/+1
C99 denotes variable-sized members with [], not [0]. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
2005-08-02Make sure leading directories exist when pushing refs.Libravatar Junio C Hamano1-0/+2
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>
2005-08-02receive-pack hooks updates.Libravatar Junio C Hamano1-10/+45
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>
2005-08-01[PATCH] Fix warning about non-void return in a void function.Libravatar A Large Angry SCM1-1/+1
Signed-off-by: A Large Angry SCM <gitzilla@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-31[PATCH] Added hook in git-receive-packLibravatar Josef Weidendorfer1-30/+58
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>
2005-07-23[PATCH] Add update-server-info.Libravatar Junio C Hamano1-0/+1
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>
2005-07-08Make "upload-pack" match git-fetch-pack usageLibravatar Linus Torvalds1-3/+1
Do the default "try xyz.git xyz fails" thing for the directory we get passed in.
2005-07-06[PATCH] Let umask do its work upon filesystem object creation.Libravatar Junio C Hamano1-1/+1
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>
2005-07-03Fix sparse warnings.Libravatar Linus Torvalds1-1/+1
Mainly making a lot of local functions and variables be marked "static", but there was a "zero as NULL" warning in there too.
2005-07-03Fix up "for_each_ref()" to be more usable, and use it in git-fsck-cacheLibravatar Linus Torvalds1-1/+1
It needed to take the GIT_DIR information into account, something that the original receive-pack usage just never cared about.
2005-07-02Generalize the "show each ref" code in receice-packLibravatar Linus Torvalds1-53/+6
This turns it into a generic "do xyz for each ref" library function.
2005-06-30Do ref matching on the sender side rather than on receiverLibravatar Linus Torvalds1-36/+7
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".
2005-06-30Add support for "forcing" a ref on the remote sideLibravatar Linus Torvalds1-2/+18
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.
2005-06-30git-receive-pack: implement ref switch command handlingLibravatar Linus Torvalds1-5/+59
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.
2005-06-29git-receive-pack: start parsing ref update commandsLibravatar Linus Torvalds1-17/+35
We don't act on them yet, but we parse them.
2005-06-29Slow but steady progress on git pack receive/sendLibravatar Linus Torvalds1-2/+4
2005-06-29Make send/receive-pack be closer to doing something interestingLibravatar Linus Torvalds1-119/+7
2005-06-29Add first cut at "git-receive-pack"Libravatar Linus Torvalds1-0/+321
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.