summaryrefslogtreecommitdiff
path: root/builtin-send-pack.c
AgeCommit message (Collapse)AuthorFilesLines
2009-01-27send-pack: do not send unknown object name from ".have" to pack-objectsLibravatar Junio C Hamano1-22/+21
v1.6.1 introduced ".have" extension to the protocol to allow the receiving side to advertise objects that are reachable from refs in the repositories it borrows from. This was meant to be used by the sending side to avoid sending such objects; they are already available through the alternates mechanism. The client side implementation in v1.6.1, which was introduced with 40c155f (push: prepare sender to receive extended ref information from the receiver, 2008-09-09) aka v1.6.1-rc1~203^2~1, were faulty in that it did not consider the possiblity that the repository receiver borrows from might have objects it does not know about. This fixes it by refraining from passing missing commits to underlying pack-objects. Revision machinery may need to be tightened further to treat missing uninteresting objects as non-error events, but this is an obvious and safe fix for a maintenance release that is almost good enough. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-08Merge branch 'maint'Libravatar Junio C Hamano1-14/+8
* maint: GIT 1.6.0.4 Update RPM spec for the new location of git-cvsserver. push: fix local refs update if already up-to-date do not force write of packed refs Conflicts: builtin-revert.c
2008-11-08Merge branch 'cb/maint-update-ref-fix' into maintLibravatar Junio C Hamano1-14/+8
* cb/maint-update-ref-fix: push: fix local refs update if already up-to-date do not force write of packed refs
2008-11-08Merge branch 'mv/maint-branch-m-symref' into maintLibravatar Junio C Hamano1-1/+1
* mv/maint-branch-m-symref: update-ref --no-deref -d: handle the case when the pointed ref is packed git branch -m: forbid renaming of a symref Fix git update-ref --no-deref -d. rename_ref(): handle the case when the reflog of a ref does not exist Fix git branch -m for symrefs.
2008-11-05push: fix local refs update if already up-to-dateLibravatar Clemens Buchacher1-14/+8
git push normally updates local refs only after a successful push. If the remote already has the updates -- pushed indirectly through another repository, for example -- we forget to update local tracking refs. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-05Merge branch 'mv/maint-branch-m-symref'Libravatar Junio C Hamano1-1/+1
* mv/maint-branch-m-symref: update-ref --no-deref -d: handle the case when the pointed ref is packed git branch -m: forbid renaming of a symref Fix git update-ref --no-deref -d. rename_ref(): handle the case when the reflog of a ref does not exist Fix git branch -m for symrefs.
2008-11-02Merge branch 'maint'Libravatar Junio C Hamano1-1/+7
* maint: Start 1.6.0.4 cycle add instructions on how to send patches to the mailing list with Gmail Documentation/gitattributes: Add subsection header for each attribute git send-email: avoid leaking directory file descriptors. send-pack: do not send out single-level refs such as refs/stash fix overlapping memcpy in normalize_absolute_path pack-objects: avoid reading uninitalized data correct cache_entry allocation Conflicts: RelNotes
2008-11-01send-pack: do not send out single-level refs such as refs/stashLibravatar Jeff King1-1/+7
Since no version of receive-pack accepts these "funny refs", we should mirror the check when considering the list of refs to send. IOW, don't even make them eligible for matching or mirroring. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-26Fix git branch -m for symrefs.Libravatar Miklos Vajna1-1/+1
This had two problems with symrefs. First, it copied the actual sha1 instead of the "pointer", second it failed to remove the old ref after a successful rename. Given that till now delete_ref() always dereferenced symrefs, a new parameters has been introduced to delete_ref() to allow deleting refs without a dereference. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-25Merge branch 'jc/alternate-push'Libravatar Shawn O. Pearce1-5/+16
* jc/alternate-push: push: receiver end advertises refs from alternate repositories push: prepare sender to receive extended ref information from the receiver receive-pack: make it a builtin is_directory(): a generic helper function
2008-09-15Start conforming code to "git subcmd" style part 3Libravatar Heikki Orsila1-1/+1
User notifications are presented as 'git cmd', and code comments are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'. Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-09push: prepare sender to receive extended ref information from the receiverLibravatar Junio C Hamano1-5/+16
"git push" enhancement allows the receiving end to report not only its own refs but refs in repositories it borrows from via the alternate object store mechanism. By telling the sender that objects reachable from these extra refs are already complete in the receiving end, the number of objects that need to be transfered can be cut down. These entries are sent over the wire with string ".have", instead of the actual names of the refs. This string was chosen so that they are ignored by older programs at the sending end. If we sent some random but valid looking refnames for these entries, "matching refs" rule (triggered when running "git push" without explicit refspecs, where the sender learns what refs the receiver has, and updates only the ones with the names of the refs the sender also has) and "delete missing" rule (triggered when "git push --mirror" is used, where the sender tells the receiver to delete the refs it itself does not have) would try to update/delete them, which is not what we want. This prepares the send-pack (and "push" that runs native protocol) to accept extended existing ref information and make use of it. The ".have" entries are excluded from ref matching rules, and are exempt from deletion rule while pushing with --mirror option, but are still used for pack generation purposes by providing more "bottom" range commits. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13Make usage strings dash-lessLibravatar Stephan Beyer1-1/+1
When you misuse a git command, you are shown the usage string. But this is currently shown in the dashed form. So if you just copy what you see, it will not work, when the dashed form is no longer supported. This patch makes git commands show the dash-less version. For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh generates a dash-less usage string now. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08make deleting a missing ref more quietLibravatar Jeff King1-2/+1
If git attempts to delete a ref, but the unlink of the ref file fails, we print a message to stderr. This is usually a good thing, but if the error is ENOENT, then it indicates that the ref has _already_ been deleted. And since that's our goal, it doesn't make sense to complain to the user. This harmonizes the error reporting behavior for the unpacked and packed cases; the packed case already printed nothing on ENOENT, but the unpacked printed unconditionally. Additionally, send-pack would, when deleting the tracking ref corresponding to a remote delete, print "Failed to delete" on any failure. This can be a misleading message, since we actually _did_ delete at the remote side, but we failed to delete locally. Rather than make the message more precise, let's just eliminate it entirely; the delete_ref routine already takes care of printing out a much more specific message about what went wrong. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04add special "matching refs" refspecLibravatar Paolo Bonzini1-1/+9
This patch provides a way to specify "push matching heads" using a special refspec ":". This is useful because it allows "push = +:" as a way to specify that matching refs will be pushed but, in addition, forced updates will be allowed, which was not possible before. Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-22remote.c: Fix overtight refspec validationLibravatar Junio C Hamano1-1/+1
We tightened the refspec validation code in an earlier commit ef00d15 (Tighten refspec processing, 2008-03-17) per my suggestion, but the suggestion was misguided to begin with and it broke this usage: $ git push origin HEAD~12:master The syntax of push refspecs and fetch refspecs are similar in that they are both colon separated LHS and RHS (possibly prefixed with a + to force), but the similarity ends there. For example, LHS in a push refspec can be anything that evaluates to a valid object name at runtime (except when colon and RHS is missing, or it is a glob), while it must be a valid-looking refname in a fetch refspec. To validate them correctly, the caller needs to be able to say which kind of refspecs they are. It is unreasonable to keep a single interface that cannot tell which kind it is dealing with, and ask it to behave sensibly. This commit separates the parsing of the two into different functions, and clarifies the code to implement the parsing proper (i.e. splitting into two parts, making sure both sides are wildcard or neither side is). This happens to also allow pushing a commit named with the esoteric "look for that string" syntax: $ git push ../test.git ':/remote.c: Fix overtight refspec:master' Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-01Clean up find_unique_abbrev() callersLibravatar Junio C Hamano1-3/+1
Now find_unique_abbrev() never returns NULL, there is no need for callers to prepare for seeing NULL and fall back to giving the full 40-hexdigits. While we are at it, drop "..." in the "git reset" output that reports the location of the new HEAD, between the abbreviated commit object name and the one line commit summary. Because we are always showing the HEAD (which cannot be missing!), we never had a case where we show the full 40 hexdigits that is not followed by three dots, and these three dots were stealing 3 columns from the precious horizontal screen real estate out of 80 that can better be used for the one line commit summary. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-23start_command(), if .in/.out > 0, closes file descriptors, not the callersLibravatar Johannes Sixt1-6/+8
Callers of start_command() can set the members .in and .out of struct child_process to a value > 0 to specify that this descriptor is used as the stdin or stdout of the child process. Previously, if start_command() was successful, this descriptor was closed upon return. Here we now make sure that the descriptor is also closed in case of failures. All callers are updated not to close the file descriptor themselves after start_command() was called. Note that earlier run_gpg_verify() of git-verify-tag set .out = 1, which worked because start_command() treated this as a special case, but now this is incorrect because it closes the descriptor. The intent here is to inherit stdout to the child, which is achieved by .out = 0. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-23start_command(), .in/.out/.err = -1: Callers must close the file descriptorLibravatar Johannes Sixt1-0/+1
By setting .in, .out, or .err members of struct child_process to -1, the callers of start_command() can request that a pipe is allocated that talks to the child process and one end is returned by replacing -1 with the file descriptor. Previously, a flag was set (for .in and .out, but not .err) to signal finish_command() to close the pipe end that start_command() had handed out, so it was optional for callers to close the pipe, and many already do so. Now we make it mandatory to close the pipe. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-02Update callers of check_ref_format()Libravatar Junio C Hamano1-4/+6
This updates send-pack and fast-import to use symbolic constants for checking the return values from check_ref_format(), and also futureproof the logic in lock_any_ref_for_update() to explicitly name the case that is usually considered an error but is Ok for this particular use. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-20send-pack: cluster ref status reportingLibravatar Jeff King1-40/+53
Instead of intermingling success and failure, we now print: 1. all uptodate refs (if args.verbose is enabled) 2. successfully pushed refs 3. failed refs with the assumption that the user is most likely to see the ones at the end, and therefore we order them from "least interesting" to "most interesting." Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-18send-pack: fix "everything up-to-date" messageLibravatar Jeff King1-1/+15
This has always been slightly inaccurate, since it used the new_refs counter, which really meant "did we send any objects," so deletions were not counted. It has gotten even worse with recent patches, since we no longer look at the 'ret' value, meaning we would say "up to date" if non-ff pushes were rejected. Instead, we now claim up to date iff every ref is either unmatched or up to date. Any other case should already have generated a status line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-18send-pack: tighten remote error reportingLibravatar Jeff King1-42/+52
Previously, we set all ref pushes to 'OK', and then marked them as errors if the remote reported so. This has the problem that if the remote dies or fails to report a ref, we just assume it was OK. Instead, we use a new non-OK state to indicate that we are expecting status (if the remote doesn't support the report-status feature, we fall back on the old behavior). Thus we can flag refs for which we expected a status, but got none (conversely, we now also print a warning for refs for which we get a status, but weren't expecting one). This also allows us to simplify the receive_status exit code, since each ref is individually marked with failure until we get a success response. We can just print the usual status table, so the user still gets a sense of what we were trying to do when the failure happened. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-17send-pack: assign remote errors to each refLibravatar Jeff King1-6/+45
This lets us show remote errors (e.g., a denied hook) along with the usual push output. There is a slightly clever optimization in receive_status that bears explanation. We need to correlate the returned status and our ref objects, which naively could be an O(m*n) operation. However, since the current implementation of receive-pack returns the errors to us in the same order that we sent them, we optimistically look for the next ref to be looked up to come after the last one we have found. So it should be an O(m+n) merge if the receive-pack behavior holds, but we fall back to a correct but slower behavior if it should change. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-17send-pack: check ref->status before updating tracking refsLibravatar Jeff King1-13/+5
Previously, we manually checked the 'NONE' and 'UPTODATE' conditions. Now that we have ref->status, we can easily say "only update if we pushed successfully". This adds a test for and fixes a regression introduced in ed31df31 where deleted refs did not have their tracking branches removed. This was due to a bogus per-ref error test that is superseded by the more accurate ref->status flag. Signed-off-by: Jeff King <peff@peff.net> Completely-Acked-By: Alex "Sleepy" Riesen <raa.lkml@gmail.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-17send-pack: track errors for each refLibravatar Jeff King1-90/+134
Instead of keeping the 'ret' variable, we instead have a status flag for each ref that tracks what happened to it. We then print the ref status after all of the refs have been examined. This paves the way for three improvements: - updating tracking refs only for non-error refs - incorporating remote rejection into the printed status - printing errors in a different order than we processed (e.g., consolidating non-ff errors near the end with a special message) Signed-off-by: Jeff King <peff@peff.net> Acked-by: Alex Riesen <raa.lkml@gmail.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14Merge branch 'aw/mirror-push' into jk/send-packLibravatar Junio C Hamano1-28/+99
* aw/mirror-push: git-push: add documentation for the newly added --mirror mode Add tests for git push'es mirror mode git-push: plumb in --mirror mode Teach send-pack a mirror mode send-pack: segfault fix on forced push send-pack: require --verbose to show update of tracking refs receive-pack: don't mention successful updates more terse push output Conflicts: transport.c transport.h
2007-11-14Merge branch 'ar/send-pack-remote-track' into jk/send-packLibravatar Junio C Hamano1-1/+2
* ar/send-pack-remote-track: Update the tracking references only if they were succesfully updated on remote Add a test checking if send-pack updated local tracking branches correctly
2007-11-14Merge branch 'db/remote-builtin' into jk/send-packLibravatar Junio C Hamano1-0/+468
* db/remote-builtin: Reteach builtin-ls-remote to understand remotes Build in ls-remote Use built-in send-pack. Build-in send-pack, with an API for other programs to call. Build-in peek-remote, using transport infrastructure. Miscellaneous const changes and utilities Conflicts: transport.c
2007-11-09Teach send-pack a mirror modeLibravatar Andy Whitcroft1-12/+34
Existing "git push --all" is almost perfect for backing up to another repository, except that "--all" only means "all branches" in modern git, and it does not delete old branches and tags that exist at the back-up repository that you have removed from your local repository. This teaches "git-send-pack" a new "--mirror" option. The difference from the "--all" option are that (1) it sends all refs, not just branches, and (2) it deletes old refs you no longer have on the local side from the remote side. Original patch by Junio C Hamano. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-08send-pack: segfault fix on forced pushLibravatar Junio C Hamano1-2/+3
When pushing to overwrite a ref that points at a commit we do not even have, the recent "terse push" patch tried to get a unique abbreviation for the non-existent (from our point of view) object, which resulted in strcpy(buf, NULL) and segfaulted. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05send-pack: require --verbose to show update of tracking refsLibravatar Jeff King1-1/+2
This is really an uninteresting detail, and it just takes attention away from the actual push updates and posssible errors. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05more terse push outputLibravatar Jeff King1-17/+64
This changes the output of send-pack to match the new, more terse fetch output. It looks like this: To git://host.tld/path/to/repo + f3325dc...3b91d1c hasforce -> mirror/hasforce (forced update) f3325dc..bb022dc master -> mirror/master ! [rejected] needsforce -> mirror/needsforce (non-fast forward) * [new branch] newbranch -> mirror/newbranch * [new tag] v1.0 -> v1.0 instead of: updating 'refs/heads/mirror/hasforce' using 'refs/heads/hasforce' from f3325dca9c4a34d74012c0e159254f454930cec7 to 3b91d1c310ca9d7b547b85466dd876e143498304 updating 'refs/heads/mirror/master' using 'refs/heads/master' from f3325dca9c4a34d74012c0e159254f454930cec7 to bb022dc363d5c2aa9aa3026beb9706d44fbe1328 error: remote 'refs/heads/mirror/needsforce' is not an ancestor of local 'refs/heads/needsforce'. Maybe you are not up-to-date and need to pull first? updating 'refs/heads/mirror/newbranch' using 'refs/heads/newbranch' from 0000000000000000000000000000000000000000 to 3b91d1c310ca9d7b547b85466dd876e143498304 updating 'refs/tags/v1.0' from 0000000000000000000000000000000000000000 to bb022dc363d5c2aa9aa3026beb9706d44fbe1328 Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02Build-in send-pack, with an API for other programs to call.Libravatar Daniel Barkalow1-0/+468
Also marks some more things as const, as needed. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>