summaryrefslogtreecommitdiff
path: root/send-pack.c
Commit message (Collapse)AuthorAgeFilesLines
* Shrink "struct object" a bitLinus Torvalds2006-06-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This shrinks "struct object" by a small amount, by getting rid of the "struct type *" pointer and replacing it with a 3-bit bitfield instead. In addition, we merge the bitfields and the "flags" field, which incidentally should also remove a useless 4-byte padding from the object when in 64-bit mode. Now, our "struct object" is still too damn large, but it's now less obviously bloated, and of the remaining fields, only the "util" (which is not used by most things) is clearly something that should be eventually discarded. This shrinks the "git-rev-list --all" memory use by about 2.5% on the kernel archive (and, perhaps more importantly, on the larger mozilla archive). That may not sound like much, but I suspect it's more on a 64-bit platform. There are other remaining inefficiencies (the parent lists, for example, probably have horrible malloc overhead), but this was pretty obvious. Most of the patch is just changing the comparison of the "type" pointer from one of the constant string pointers to the appropriate new TYPE_xxx small integer constant. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* sha1_name: warning ambiguous refs.Junio C Hamano2006-03-231-0/+2
| | | | | | | | | This makes sure that many commands that take refs on the command line to honor core.warnambiguousrefs configuration. Earlier, the commands affected by this patch did not read the configuration file. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Const tightening.Junio C Hamano2006-03-051-2/+2
| | | | | | | | | 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>
*-. Merge branches 'jc/rev-list' and 'jc/pack-thin'Junio C Hamano2006-02-241-1/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/rev-list: rev-list --objects: use full pathname to help hashing. rev-list --objects-edge: remove duplicated edge commit output. rev-list --objects-edge * jc/pack-thin: pack-objects: hash basename and direname a bit differently. pack-objects: allow "thin" packs to exceed depth limits pack-objects: use full pathname to help hashing with "thin" pack. pack-objects: thin pack micro-optimization. Use thin pack transfer in "git fetch". Add git-push --thin. send-pack --thin: use "thin pack" delta transfer. Thin pack - create packfile with missing delta base. Conflicts: pack-objects.c (taking "next") send-pack.c (taking "next")
| | * send-pack --thin: use "thin pack" delta transfer.Junio C Hamano2006-02-191-1/+9
| |/ | | | | | | | | | | | | | | | | The new flag loosens the usual "self containedness" requirment of packfiles, and sends deltified representation of objects when we know the other side has the base objects needed to unpack them. This would help reducing the transfer size. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | send-pack: do not give up when remote has insanely large number of refs.Junio C Hamano2006-02-221-10/+28
|/ | | | | | | | | | | Stephen C. Tweedie noticed that we give up running rev-list when we see too many refs on the remote side. Limit the number of negative references we give to rev-list and continue. Not sending any negative references to rev-list is very bad -- we may be pushing a ref that is new to the other end. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Exec git programs without using PATH.Michal Ostrowski2006-01-131-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* send-pack/receive-pack: allow errors to be reported back to pusher.Junio C Hamano2005-12-271-3/+56
| | | | | | | | | | | 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>
* send-pack: reword non-fast-forward error message.Junio C Hamano2005-12-221-16/+14
| | | | | | | | | | | | | | Wnen refusing to push a head, we said cryptic "remote 'branch' object X does not exist on local" or "remote ref 'branch' is not a strict subset of local ref 'branch'". That was gittish. Since the most likely reason this happens is because the pushed head was not up-to-date, clarify the error message to say that straight, and suggest pulling first. First noticed by Johannes and seconded by Andreas. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Avoid misleading success message on errorJohannes Schindelin2005-12-211-1/+1
| | | | | | | | When a push fails (for example when the remote head does not fast forward to the desired ref) it is not correct to print "Everything up-to-date". Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make "git-send-pack" less verbose by defaultLinus Torvalds2005-12-201-1/+9
| | | | | | | | | | | | | | | | | | | | | | It used to make sense to have git-send-pack talk about the things it sent when (a) it was a new program and (b) nobody had a lot of tags and branches. These days, it's just distracting to see tons of 'refs/tags/xyz': up-to-date ... when updating a remote repo. So shut it up by default, and add a "--verbose" flag for those who really want to see it. Also, since this makes he case of everything being up-to-date just totally silent, make it say "Everything up-to-date" if no refs needed updating. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make git-send-pack exit with error when some refs couldn't be pushed outPetr Baudis2005-12-131-1/+5
| | | | | | | | | | | | In case some refs couldn't be pushed out due to an error (mostly the not-a-proper-subset error), make git-send-pack exit with non-zero status after the push is over (that is, it still tries to push out the rest of the refs). [jc: I adjusted a test for this change.] Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Warn when send-pack does nothingDaniel Barkalow2005-12-041-0/+6
| | | | | | | | | | If you try to push into an empty repository with no ref arguments to git push, it doesn't do anything and doesn't say anything. This adds a warning when send-pack isn't going to push anything, so you don't assume that it silently did what you wanted. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make networking commands to work from a subdirectory.Junio C Hamano2005-11-281-0/+1
| | | | | | | | | These are whole-tree operations and there is not much point making them operable from within a subdirectory, but it is easy to do so, and using setup_git_directory() upfront helps git:// proxy specification picked up from the correct place. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Be careful when dereferencing tags.Junio C Hamano2005-11-021-2/+2
| | | | | | | | | | One caller of deref_tag() was not careful enough to make sure what deref_tag() returned was not NULL (i.e. we found a tag object that points at an object we do not have). Fix it, and warn about refs that point at such an incomplete tag where needed. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Ignore funny refname sent from remoteJunio C Hamano2005-10-151-1/+1
| | | | | | | | | This allows the remote side (most notably, upload-pack) to show additional information without affecting the downloader. Peek-remote does not ignore them -- this is to make it useful for Pasky's automatic tag following. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Support +<src>:<dst> format in push as well.Junio C Hamano2005-08-241-4/+8
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix ref_newer() in send-pack.Junio C Hamano2005-08-051-5/+22
| | | | | | | | | | When more than two references need to be checked with ref_newer() function, the second and later calls did not work correctly. This was because the later calls found commits retained by the "struct object" layer that still had smudges made by earlier calls. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix send-pack for non-commitish tags.Junio C Hamano2005-08-051-13/+42
| | | | | | | | | | | | | | | | | | | Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Renaming push.Junio C Hamano2005-08-031-91/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
* send-pack: handle partial pushes correctly.Junio C Hamano2005-08-031-1/+8
| | | | | | | | | | | | | | | | | When pushing into multi-user repository, or when pushing to a repository from a local repository that has rebased branches that has been pruned, the destination repository can have head commits that are missing from the local repository. This should not matter as long as the local head of the branch being pushed is a proper superset of the destination branch, but we ended up trying to run rev-list telling it to exclude objects reachable from those heads missing from the local repository, causing it to barf. Prune those heads from the rev-list parameter list, and make sure we do not try to push a branch whose remote head is something we lack. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make send-pack --all and explicit ref mutually exclusive.Junio C Hamano2005-08-021-2/+5
| | | | | | | | | send-pack had a confusing misfeature that "send-pack --all master" updated all refs, while "send-pack --all" did not do anything. Make --all and explicit refs mutually exclusive, and make sure "send-pack --all" updates all refs. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix potential send-pack SIGSEGVLinus Torvalds2005-07-261-1/+2
| | | | | | | | | | | | | The check that the source is ahead of the destination incorrectly expects pop_most_recent_commit() to gracefully handle an empty list. Fix by just checking the list itself, rather than the return value of the pop function. [jc: I did the test script that demonstrated the problem] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-send-pack: verify that sender is a proper superset of receiverLinus Torvalds2005-07-191-10/+26
| | | | | | This should make sure that if you have multiple people pushing to the same tree, they cannot overwrite each others work, but have to merge before being able to update the common reference tree.
* Merge three separate "fetch refs" functionsLinus Torvalds2005-07-161-34/+3
| | | | | It really just boils down to one "get_remote_heads()" function, and a common "struct ref" structure definition.
* git-send-pack: add "--all" option to send all refs to the other sideLinus Torvalds2005-07-161-10/+28
| | | | | This affects only refs that the other side doesn't already have. The ones it has are still filtered by the ref selection.
* [PATCH] Documentation: send/receive.Junio C Hamano2005-07-141-1/+2
| | | | | | | This adds documentation for 'smarter push' family of commands. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* git-send-pack: Fix duplicate refname matchLinus Torvalds2005-07-111-3/+0
| | | | | | | | | Cut-and-paste dup noticed by Junio. It's not even harmless, since a match also causes that match to be invalidated, so this made it impossible to update an existing branch by name. I'd only tested the case of "ref doesn't exist at all on the other end", which worked fine.
* Teach 'git-send-pack' to send new branches and tags.Linus Torvalds2005-07-081-17/+111
| | | | | | | | | The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
* Add "git_path()" and "head_ref()" helper functions.Linus Torvalds2005-07-051-4/+1
| | | | | | | "git_path()" returns a static pathname pointer into the git directory using a printf-like format specifier. "head_ref()" works like "for_each_ref()", except for just the HEAD.
* Move ref path matching to connect.c libraryLinus Torvalds2005-07-041-21/+0
| | | | It's a generic thing for matching refs from the other side.
* Factor out the ssh connection stuff from send-pack.cLinus Torvalds2005-07-041-73/+2
| | | | I want to use it for git-fetch-pack too.
* Fix gcc warning in send-pack.cLinus Torvalds2005-07-031-0/+1
| | | | | send_pack() was declared to return "int" (although nobody cared), but didn't actually return anything.
* Do ref matching on the sender side rather than on receiverLinus Torvalds2005-06-301-3/+25
| | | | | | | | | | | | 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".
* git-send-pack: actually send the object packLinus Torvalds2005-06-301-12/+79
| | | | | | | | This concludes this lesson. I've actually successfully sent an update using the git-send-pack command. Probably tons of work still to do, and nasty debugging, but it's now actually potentially useful.
* Add comment on what send-pack still needs to doLinus Torvalds2005-06-291-0/+11
| | | | Me tired.
* Slow but steady progress on git pack receive/sendLinus Torvalds2005-06-291-25/+38
|
* git-send-pack: start parsing local/remote reference differencesLinus Torvalds2005-06-291-3/+58
| | | | | Right now it just shows which refs it picks up, and whether they are the same or changed on the remote end. Getting there..
* Make send/receive-pack be closer to doing something interestingLinus Torvalds2005-06-291-4/+8
|
* Start of "git-send-pack", the local part of sending off a packLinus Torvalds2005-06-291-0/+118
Like git-receive-pack, this is only partway done.