path: root/builtin/send-pack.c
AgeCommit message (Collapse)Author
2013-02-24teach get_remote_heads to read from a memory bufferJeff King
Now that we can read packet data from memory as easily as a descriptor, get_remote_heads can take either one as a source. This will allow further refactoring in remote-curl. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2013-02-20pkt-line: drop safe_write functionJeff King
This is just write_or_die by another name. The one distinction is that write_or_die will treat EPIPE specially by suppressing error messages. That's fine, as we die by SIGPIPE anyway (and in the off chance that it is disabled, write_or_die will simulate it). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2013-01-24push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCEJunio C Hamano
When we push to update an existing ref, if: * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, it won't be correct to suggest to fetch, integrate and push again, as the old and new objects will not "merge". We should explain that the push must be forced when there is a non-committish object is involved in such a case. If we do not have the current object at the tip of the remote, we do not even know that object, when fetched, is something that can be merged. In such a case, suggesting to pull first just like non-fast-forward case may not be technically correct, but in practice, most such failures are seen when you try to push your work to a branch without knowing that somebody else already pushed to update the same branch since you forked, so "pull first" would work as a suggestion most of the time. And if the object at the tip is not a commit, "pull first" will fail, without making any permanent damage. As a side effect, it also makes the error message the user will get during the next "push" attempt easier to understand, now the user is aware that a non-commit object is involved. In these cases, the current code already rejects such a push on the client end, but we used the same error and advice messages as the ones used when rejecting a non-fast-forward push, i.e. pull from there and integrate before pushing again. Introduce new rejection reasons and reword the messages appropriately. [jc: with help by Peff on message details] Signed-off-by: Junio C Hamano <>
2012-12-02push: require force for refs under refs/tags/Chris Rorvick
References are allowed to update from one commit-ish to another if the former is an ancestor of the latter. This behavior is oriented to branches which are expected to move with commits. Tag references are expected to be static in a repository, though, thus an update to something under refs/tags/ should be rejected unless the update is forced. Signed-off-by: Chris Rorvick <> Signed-off-by: Junio C Hamano <>
2012-12-02push: return reject reasons as a bitsetChris Rorvick
Pass all rejection reasons back from transport_push(). The logic is simpler and more flexible with regard to providing useful feedback. Signed-off-by: Chris Rorvick <> Signed-off-by: Junio C Hamano <>
2012-10-29send-pack: move core code to libgit.aNguyễn Thái Ngọc Duy
send_pack() is used by transport.c, part of libgit.a while it stays in builtin/send-pack.c. Move it to send-pack.c so that we won't get undefined reference if a program that uses libgit.a happens to pull it in. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Jeff King <>
2012-08-10do not send client agent unless server does firstJeff King
Commit ff5effdf taught both clients and servers of the git protocol to send an "agent" capability that just advertises their version for statistics and debugging purposes. The protocol-capabilities.txt document however indicates that the client's advertisement is actually a response, and should never include capabilities not mentioned in the server's advertisement. Adding the unconditional advertisement in the server programs was OK, then, but the clients broke the protocol. The server implementation of git-core itself does not care, but at least one does: the Google Code git server (or any server using Dulwich), will hang up with an internal error upon seeing an unknown capability. Instead, each client must record whether we saw an agent string from the server, and respond with its agent only if the server mentioned it first. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-08-10send-pack: fix capability-sending logicJeff King
If we have capabilities to send to the server, we send the regular "want" line followed by a NUL, then the capabilities; otherwise, we do not even send the NUL. However, when checking whether we want to send the "quiet" capability, we check args->quiet, which is wrong. That flag only tells us whether the client side wanted to be quiet, not whether the server supports it (originally, in c207e34f, it meant both; however, that was later split into two flags by 01fdc21f). We still check the right flag when actually printing "quiet", so this could only have two effects: 1. We might send the trailing NUL when we do not otherwise need to. In theory, an antique pre-capability implementation of git might choke on this (since the client is instructed never to respond with capabilities that the server has not first advertised). 2. We might also want to send the quiet flag if the args->progress flag is false, but this code path would not trigger in that instance. In practice, it almost certainly never matters. The report-status capability dates back to 2005. Any real-world server is going to advertise that, and we will always respond with at least that capability. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-08-03include agent identifier in capability stringJeff King
Instead of having the client advertise a particular version number in the git protocol, we have managed extensions and backwards compatibility by having clients and servers advertise capabilities that they support. This is far more robust than having each side consult a table of known versions, and provides sufficient information for the protocol interaction to complete. However, it does not allow servers to keep statistics on which client versions are being used. This information is not necessary to complete the network request (the capabilities provide enough information for that), but it may be helpful to conduct a general survey of client versions in use. We already send the client version in the user-agent header for http requests; adding it here allows us to gather similar statistics for non-http requests. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-05-01teach send-pack about --[no-]progressJeff King
The send_pack function gets a "progress" flag saying "yes, definitely show progress" or "no, definitely do not show progress". This gets set properly by transport_push when send_pack is called directly. However, when the send-pack command is executed separately (as it is for the remote-curl helper), there is no way to tell it "definitely do this". As a result, we do not properly respect "git push --no-progress" for smart-http remotes; you will still get progress if stderr is a tty. This patch teaches send-pack --progress and --no-progress, and teaches remote-curl to pass the appropriate option to override send-pack's isatty check. This fixes the --no-progress case above, and as a bonus, also makes "git push --progress" work when stderr is not a tty. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-05-01send-pack: show progress when isatty(2)Jeff King
The send_pack_args struct has two verbosity flags: "quiet" and "progress". Originally, if "quiet" was set, we would tell pack-objects explicitly to be quiet, and if "progress" was set, we would tell it to show progress. Otherwise, we told it neither, and it relied on isatty(2) to make the decision itself. However, commit 01fdc21 changed the meaning of these variables. Now both "quiet" and "!progress" instruct us to tell pack-objects to be quiet (and a non-zero "progress" means the same as before). This works well for transports which call send_pack directly, as the transport code copies transport->progress into send_pack_args->progress, and they both have the same meaning. However, the code path of calling "git send-pack" was left behind. It always sets "progress" to 0, and thus always tells pack-objects to be quiet. We can work around this by checking isatty(2) ourselves in the cmd_send_pack code path, restoring the original behavior of the send-pack command. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-02-13push/fetch/clone --no-progress suppresses progress outputClemens Buchacher
By default, progress output is disabled if stderr is not a terminal. The --progress option can be used to force progress output anyways. Conversely, --no-progress does not force progress output. In particular, if stderr is a terminal, progress output is enabled. This is unintuitive. Change --no-progress to force output off. Signed-off-by: Clemens Buchacher <> Signed-off-by: Junio C Hamano <>
2012-01-08fix push --quiet: add 'quiet' capability to receive-packClemens Buchacher
Currently, git push --quiet produces some non-error output, e.g.: $ git push --quiet Unpacking objects: 100% (3/3), done. This fixes a bug reported for the fedora git package: Reported-by: Jesse Keating <> Cc: Todd Zullinger <> Commit 90a6c7d4 (propagate --quiet to send-pack/receive-pack) introduced the --quiet option to receive-pack and made send-pack pass that option. Older versions of receive-pack do not recognize the option, however, and terminate immediately. The commit was therefore reverted. This change instead adds a 'quiet' capability to receive-pack, which is a backwards compatible. In addition, this fixes push --quiet via http: A verbosity of 0 means quiet for remote helpers. Reported-by: Tobias Ulmer <> Signed-off-by: Clemens Buchacher <> Signed-off-by: Junio C Hamano <>
2011-12-13drop "match" parameter from get_remote_headsJeff King
The get_remote_heads function reads the list of remote refs during git protocol session. It dates all the way back to def88e9 (Commit first cut at "git-fetch-pack", 2005-07-04). At that time, the idea was to come up with a list of refs we were interested in, and then filter the list as we got it from the remote side. Later, 1baaae5 (Make maximal use of the remote refs, 2005-10-28) stopped filtering at the get_remote_heads layer, letting us use the non-matching refs to find common history. As a result, all callers now simply pass an empty match list (and any future callers will want to do the same). So let's drop these now-useless parameters. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-09-12rename "match_refs()" to "match_push_refs()"Junio C Hamano
Yes, there is a warning that says the function is only used by push in big red letters in front of this function, but it didn't say a more important thing it should have said: what the function is for and what it does. Rename it and document it to avoid future confusion. Signed-off-by: Junio C Hamano <>
2011-09-12send-pack: typofix error messageJunio C Hamano
The message identifies the process as receive-pack when it cannot fork the sideband demultiplexer. We are actually a send-pack. Signed-off-by: Junio C Hamano <>
2011-09-06Revert "Merge branch 'cb/maint-quiet-push' into maint"Junio C Hamano
This reverts commit ffa69e61d3c5730bd4b65a465efc130b0ef3c7df, reversing changes made to 4a13c4d14841343d7caad6ed41a152fee550261d. Adding a new command line option to receive-pack and feed it from send-pack is not an acceptable way to add features, as there is no guarantee that your updated send-pack will be talking to updated receive-pack. New features need to be added via the capability mechanism negotiated over the protocol. Signed-off-by: Junio C Hamano <>
2011-08-01propagate --quiet to send-pack/receive-packClemens Buchacher
Currently, git push --quiet produces some non-error output, e.g.: $ git push --quiet Unpacking objects: 100% (3/3), done. Add the --quiet option to send-pack/receive-pack and pass it to unpack-objects in the receive-pack codepath and to receive-pack in the push codepath. This fixes a bug reported for the fedora git package: Reported-by: Jesse Keating <> Cc: Todd Zullinger <> Signed-off-by: Clemens Buchacher <> Signed-off-by: Junio C Hamano <>
2011-05-20Merge branch 'jk/git-connection-deadlock-fix'Junio C Hamano
* jk/git-connection-deadlock-fix: test core.gitproxy configuration send-pack: avoid deadlock on git:// push with failed pack-objects connect: let callers know if connection is a socket connect: treat generic proxy processes like ssh processes Conflicts: connect.c
2011-05-20Merge branch 'js/maint-send-pack-stateless-rpc-deadlock-fix'Junio C Hamano
* js/maint-send-pack-stateless-rpc-deadlock-fix: sideband_demux(): fix decl-after-stmt
2011-05-13Merge branch 'js/maint-send-pack-stateless-rpc-deadlock-fix'Junio C Hamano
* js/maint-send-pack-stateless-rpc-deadlock-fix: send-pack: unbreak push over stateless rpc send-pack: avoid deadlock when pack-object dies early
2011-03-22Fix sparse warningsStephen Boyd
Fix warnings from 'make check'. - These files don't include 'builtin.h' causing sparse to complain that cmd_* isn't declared: builtin/clone.c:364, builtin/fetch-pack.c:797, builtin/fmt-merge-msg.c:34, builtin/hash-object.c:78, builtin/merge-index.c:69, builtin/merge-recursive.c:22 builtin/merge-tree.c:341, builtin/mktag.c:156, builtin/notes.c:426 builtin/notes.c:822, builtin/pack-redundant.c:596, builtin/pack-refs.c:10, builtin/patch-id.c:60, builtin/patch-id.c:149, builtin/remote.c:1512, builtin/remote-ext.c:240, builtin/remote-fd.c:53, builtin/reset.c:236, builtin/send-pack.c:384, builtin/unpack-file.c:25, builtin/var.c:75 - These files have symbols which should be marked static since they're only file scope: submodule.c:12, diff.c:631, replace_object.c:92, submodule.c:13, submodule.c:14, trace.c:78, transport.c:195, transport-helper.c:79, unpack-trees.c:19, url.c:3, url.c:18, url.c:104, url.c:117, url.c:123, url.c:129, url.c:136, thread-utils.c:21, thread-utils.c:48 - These files redeclare symbols to be different types: builtin/index-pack.c:210, parse-options.c:564, parse-options.c:571, usage.c:49, usage.c:58, usage.c:63, usage.c:72 - These files use a literal integer 0 when they really should use a NULL pointer: daemon.c:663, fast-import.c:2942, imap-send.c:1072, notes-merge.c:362 While we're in the area, clean up some unused #includes in builtin files (mostly exec_cmd.h). Signed-off-by: Stephen Boyd <> Signed-off-by: Junio C Hamano <>
2010-11-17Merge branch 'jk/push-progress'Junio C Hamano
* jk/push-progress: push: pass --progress down to git-pack-objects t5523-push-upstream: test progress messages t5523-push-upstream: add function to ensure fresh upstream repo test_terminal: ensure redirections work reliably test_terminal: catch use without TTY prerequisite test-lib: allow test code to check the list of declared prerequisites tests: test terminal output to both stdout and stderr tests: factor out terminal handling from t7006
2010-10-18push: pass --progress down to git-pack-objectsJeff King
When pushing via builtin transports (like file://, git://), the underlying transport helper (in this case, git-pack-objects) did not get the --progress option, even if it was passed to git push. Fix this, and update the tests to reflect this. Note that according to the git-pack-objects documentation, we can safely apply the usual --progress semantics for the transport commands like clone and fetch (and for pushing over other smart transports). Reported-by: Chase Brammer <> Helped-by: Jonathan Nieder <> Signed-off-by: Jeff King <> Signed-off-by: Tay Ray Chuan <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-10-18send-pack: avoid redundant "pack-objects died with strange error"Jonathan Nieder
Saying "pack-objects died with strange error" after "pack-objects died of signal 13" seems kind of redundant. The latter message was introduced when the run-command API changed to report abnormal exits on behalf of the caller (v1.6.5-rc0~86^2~5, 2009-07-04). Similarly, after a controlled pack-objects failure (detectable as a normal exit with nonzero status), a "died with strange error" message would be redundant next to the message from pack-objects itself. So leave off the "strange error" messages. The result should look something like this: $ git push sf master Counting objects: 21542, done. Compressing objects: 100% (4179/4179), done. fatal: Unable to create temporary file: Permission denied error: pack-objects died of signal 13 error: failed to push some refs to 'ssh://' $ Or in the "controlled exit" case (contrived example): [...] fatal: delta size changed error: failed to push some refs to 'ssh://' $ Improved-by: Johannes Sixt <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-03-15Merge branch 'ld/push-porcelain'Junio C Hamano
* ld/push-porcelain: t5516: Use test_cmp when appropriate git-push: add tests for git push --porcelain git-push: make git push --porcelain print "Done" git-push: send "To <remoteurl>" messages to the standard output in --porcelain mode git-push: fix an advice message so it goes to stderr Conflicts: transport.c
2010-03-10Merge branch 'lt/deepen-builtin-source'Junio C Hamano
* lt/deepen-builtin-source: Move 'builtin-*' into a 'builtin/' subdirectory Conflicts: Makefile
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLinus Torvalds
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>