summaryrefslogtreecommitdiff
path: root/transport-helper.c
AgeCommit message (Collapse)AuthorFilesLines
2013-05-09Sync with v1.8.2.3Libravatar Junio C Hamano1-2/+1
* maint: Git 1.8.2.3 t5004: avoid using tar for checking emptiness of archive t5004: ignore pax global header file mergetools/kdiff3: do not use --auto when diffing transport-helper: trivial style cleanup
2013-05-09transport-helper: trivial style cleanupLibravatar Felipe Contreras1-2/+1
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-05Merge branch 'fc/push-with-export-reporting-result'Libravatar Junio C Hamano1-0/+1
* fc/push-with-export-reporting-result: transport-helper: improve push messages
2013-05-05transport-helper: improve push messagesLibravatar Felipe Contreras1-0/+1
If there's already a remote-helper tracking ref, we can fetch the SHA-1 to report proper push messages (as opposed to always reporting [new branch]). The remote-helper currently can specify the old SHA-1 to avoid this problem, but there's no point in forcing all remote-helpers to be aware of git commit ids; they should be able to be agnostic of them. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15transport-helper: add 'signed-tags' capabilityLibravatar John Keeping1-1/+5
This allows a remote helper using the 'export' protocol to specify that it supports signed tags, changing the handing from 'warn-strip' to 'verbatim'. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15transport-helper: pass --signed-tags=warn-strip to fast-exportLibravatar John Keeping1-1/+2
Currently, attempting to push a signed tag to a remote helper which uses fast-export results in the remote helper failing because the default fast-export action for signed tags is "abort". This is not helpful for users because there is no way to pass additional arguments to fast-export here, either from the remote helper or from the command line. In general, the signature will be invalidated by whatever transformation a remote helper performs on a tag to push it to a repository in a different format so the correct behaviour is to strip the tag. Doing this silently may surprise people, so use "warn-strip" to issue a warning when a signed tag is encountered. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12Correct common spelling mistakes in comments and testsLibravatar Stefano Lattarini1-1/+1
Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-24push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCELibravatar Junio C Hamano1-0/+10
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 <gitster@pobox.com>
2012-12-02push: require force for refs under refs/tags/Libravatar Chris Rorvick1-0/+6
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 <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-07When debug==1, start fast-import with "--stats" instead of "--quiet"Libravatar Florian Achleitner1-1/+1
fast-import prints statistics that could be interesting to the developer of remote helpers. Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com> Acked-by: David Michael Barr <b@rr-dav.id.au> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-07Connect fast-import to the remote-helper via pipe, adding 'bidi-import' ↵Libravatar Florian Achleitner1-13/+31
capability The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers to retrieve information about blobs and trees that already exist in fast-import's memory. This requires a channel from fast-import to the remote-helper. remote-helpers that use these features shall advertise the new 'bidi-import' capability to signal that they require the communication channel. When forking fast-import in transport-helper.c connect it to a dup of the remote-helper's stdin-pipe. The additional file descriptor is passed to fast-import via its command line (--cat-blob-fd). It follows that git and fast-import are connected to the remote-helpers's stdin. Because git can send multiple commands to the remote-helper on it's stdin, it is required that helpers that advertise 'bidi-import' buffer all input commands until the batch of 'import' commands is ended by a newline before sending data to fast-import. This is to prevent mixing commands and fast-import responses on the helper's stdin. Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com> Acked-by: David Michael Barr <b@rr-dav.id.au> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-30Add explanatory comment for transport-helpers refs mapping.Libravatar Florian Achleitner1-0/+15
The patch below adds a comment to fetch_with_import() explaining the loop that saves the fetched commit names after 'git fast-import' has done its work. It avoids some confusion about which refs the fast-import stream is supposed to use to write its result. Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-30remove superfluous newlines in error messagesLibravatar Pete Wyckoff1-2/+2
The error handling routines add a newline. Remove the duplicate ones in error messages. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-26Merge branch 'sp/smart-http-failure-to-push'Libravatar Junio C Hamano1-3/+10
* sp/smart-http-failure-to-push: : Mask SIGPIPE on the command channel going to a transport helper disconnect from remote helpers more gently Conflicts: transport-helper.c
2012-02-23disconnect from remote helpers more gentlyLibravatar Jeff King1-3/+10
When git spawns a remote helper program (like git-remote-http), the last thing we do before closing the pipe to the child process is to send a blank line, telling the helper that we are done issuing commands. However, the helper may already have exited, in which case the parent git process will receive SIGPIPE and die. In particular, this can happen with the remote-curl helper when it encounters errors during a push. The helper reports individual errors for each ref back to git-push, and then exits with a non-zero exit code. Depending on the exact timing of the write, the parent process may or may not receive SIGPIPE. This causes intermittent test failure in t5541.8, and is a side effect of 5238cbf (remote-curl: Fix push status report when all branches fail). Before that commit, remote-curl would not send the final blank line to indicate that the list of status lines was complete; it would just exit, closing the pipe. The parent git-push would notice the closed pipe while reading the status report and exit immediately itself, propagating the failing exit code. But post-5238cbf, remote-curl completes the status list before exiting, git-push actually runs to completion, and then it tries to cleanly disconnect the helper, leading to the SIGPIPE race above. This patch drops all error-checking when sending the final "we are about to hang up" blank line to helpers. There is nothing useful for the parent process to do about errors at that point anyway, and certainly failing to send our "we are done with commands" line to a helper that has already exited is not a problem. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05remote: avoid passing NULL to read_ref()Libravatar Michael Haggerty1-2/+4
read_ref() can (and in test t5800, actually *does*) return NULL. Don't pass the NULL along to read_ref(). Coincidentally, this mistake didn't make resolve_ref() blow up, but upcoming changes to resolve_ref() will make it less forgiving. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05remote: use xstrdup() instead of strdup()Libravatar Michael Haggerty1-2/+2
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: die early on encountering deleted refsLibravatar Sverre Rabbelier1-0/+4
Remote helpers do not support deleting refs by means of the 'export' command sincethe fast-import protocol does not support it. Check explicitly for deleted refs and die early. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: implement marks location as capabilityLibravatar Sverre Rabbelier1-29/+18
Now that the gitdir location is exported as an environment variable this can be implemented elegantly without requiring any explicit flushes nor an ad-hoc exchange of values. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: Use capname for refspec capability tooLibravatar Sverre Rabbelier1-1/+1
Previously the refspec capability could not be listed as required or their parsing would break. Most likely the reason the second hunk wasn't caught is because the series that added 'refspec' as capability, and the one that added required capabilities were done in parallel. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: change import semanticsLibravatar Sverre Rabbelier1-0/+3
Currently the helper must somehow guess how many import statements to read before it starts outputting its fast-export stream. This is because the remote helper infrastructure runs fast-import only once, so the helper is forced to output one stream for all import commands it will receive. The only reason this worked in the past was because only one ref was imported at a time. Change the semantics of the import statement such that it matches that of the push statement. That is, the import statement is followed by a series of import statements that are terminated by a '\n'. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: update ref status after push with exportLibravatar Sverre Rabbelier1-0/+1
Also add check_output from python 2.7. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: use the new done feature where possibleLibravatar Sverre Rabbelier1-7/+2
In other words, use fast-export --use-done-feature to add a 'done' command at the end of streams passed to remote helpers' "import" commands, and teach the remote helpers implementing "export" to use the 'done' command in turn when producing their streams. The trailing \n in the protocol signals the helper that the connection is about to close, allowing it to do whatever cleanup neccesary. Previously, the connection would already be closed by the time the trailing \n was to be written. Now that the remote-helper protocol uses the new done command in its fast-import streams, this is no longer the case and we can safely write the trailing \n. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: check status code of finish_commandLibravatar Sverre Rabbelier1-8/+15
Previously the status code of all helpers were ignored, allowing errors that occur to go unnoticed if the error text output by the helper is not noticed. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: factor out push_update_refs_statusLibravatar Sverre Rabbelier1-69/+84
The update ref status part of push is useful for the export command as well, factor it out into it's own function. Also factor out push_update_ref_status to avoid a long loop without an explicit condition with a non-trivial body. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19remote-helpers: export GIT_DIR variable to helpersLibravatar Dmitry Ivankov1-5/+10
The gitdir capability is recognized by git and can be used to tell the helper where the .git directory is. But it is not mentioned in the documentation and considered worse than if gitdir was passed via GIT_DIR environment variable. Remove support for the gitdir capability and export GIT_DIR instead. Teach testgit to use env instead of the now-removed gitdir command. [sr: fixed up documentation] Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: don't feed bogus refs to export pushLibravatar Jeff King1-1/+2
When we want to push to a remote helper that has the "export" capability, we collect all of the refs we want to push and then feed them to fast-export. However, the list of refs is actually a list of remote refs, not local refs. The mapped local refs are included via the peer_ref pointer. So when we add an argument to our fast-export command line, we must be sure to use the local peer_ref name (and if there is no local name, it is because we are not actually sending that ref, or we may not even have the ref at all). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: fix minor leak in push_refs_with_exportLibravatar Jeff King1-0/+1
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-22Remove unused variablesLibravatar Johannes Schindelin1-2/+1
Noticed by gcc 4.6.0. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-22Fix sparse warningsLibravatar Stephen Boyd1-1/+1
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 <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-16Merge branch 'maint'Libravatar Junio C Hamano1-2/+1
* maint: Prepare draft release notes to 1.7.4.2 gitweb: highlight: replace tabs with spaces make_absolute_path: return the input path if it points to our buffer valgrind: ignore SSE-based strlen invalid reads diff --submodule: split into bite-sized pieces cherry: split off function to print output lines branch: split off function that writes tracking info and commit subject standardize brace placement in struct definitions compat: make gcc bswap an inline function enums: omit trailing comma for portability Conflicts: RelNotes
2011-03-16standardize brace placement in struct definitionsLibravatar Jonathan Nieder1-2/+1
In a struct definitions, unlike functions, the prevailing style is for the opening brace to go on the same line as the struct name, like so: struct foo { int bar; char *baz; }; Indeed, grepping for 'struct [a-z_]* {$' yields about 5 times as many matches as 'struct [a-z_]*$'. Linus sayeth: Heretic people all over the world have claimed that this inconsistency is ... well ... inconsistent, but all right-thinking people know that (a) K&R are _right_ and (b) K&R are right. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-08transport-helper.c: fix check for (size_t < 0)Libravatar Nicolas Kaiser1-1/+1
'bytes' is of type size_t which is unsigned thus can't be negative. But the assigned write() returns ssize_t, and -1 on error. For testing < 0, 'bytes' needs to be of a signed type. Signed-off-by: Nicolas Kaiser <nikai@nikai.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-10thread-utils.h: simplify the inclusionLibravatar Junio C Hamano1-4/+0
All files that include this header file use the same four line incantation: #ifndef NO_PTHREADS #include <pthread.h> #include "thread-utils.h" #endif Move the responsibility for that gymnastics to the header file from the files that include it. This approach makes it easier to later declare new services that are related to threading in thread-utils.h and have them available to all the threading code. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-19remote-fd/ext: finishing touches after code reviewLibravatar Ilari Liusvaara1-0/+5
When compiling with pthread support, transport-helper.c needs to include necessary header files. Also fix a few error messages in remote-ext and remote-fd programs, and a potential buffer underrun in remote-fd. In the documentation, clarify how %G and %V are used; the old description looked as if they take repository/vhost parameters, which was wrong. Also fix AsciiDoc markup for the page title of remote-fd/remote-ext manpages, and tweak the way how section headers are shown. Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-13Add bidirectional_transfer_loop()Libravatar Ilari Liusvaara1-0/+311
This helper function copies bidirectional stream of data between stdin/stdout and specified file descriptors. Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05string_list: Add STRING_LIST_INIT macro and make use of it.Libravatar Thiago Farina1-1/+1
Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Thiago Farina <tfransosi@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27string_list: Fix argument order for string_list_appendLibravatar Julian Phillips1-2/+2
Update the definition and callers of string_list_append to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-31remote-helpers: add support for an export commandLibravatar Sverre Rabbelier1-12/+120
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-31remote-helpers: allow requesing the path to the .git directoryLibravatar Sverre Rabbelier1-0/+5
The 'gitdir' capability is reported by the remote helper if it requires the location of the .git directory. The location of the .git directory can then be used by the helper to store status files even when the current directory is not a git repository (such as is the case when cloning). The location of the .git dir is specified as an absolute path. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-15Merge branch 'tc/transport-verbosity'Libravatar Junio C Hamano1-3/+1
* tc/transport-verbosity: transport: update flags to be in running order fetch and pull: learn --progress push: learn --progress transport->progress: use flag authoritatively clone: support multiple levels of verbosity push: support multiple levels of verbosity fetch: refactor verbosity option handling into transport.[ch] Documentation/git-push: put --quiet before --verbose Documentation/git-pull: put verbosity options before merge/fetch ones Documentation/git-clone: mention progress in -v Conflicts: transport.h
2010-02-24transport->progress: use flag authoritativelyLibravatar Tay Ray Chuan1-2/+1
Set transport->progress in transport.c::transport_set_verbosity() after checking for the appropriate conditions (eg. --progress, isatty(2)), and thereafter use it without having to check again. The rules used are as follows (processing aborts when a rule is satisfied): 1. Report progress, if force_progress is 1 (ie. --progress). 2. Don't report progress, if verbosity < 0 (ie. -q/--quiet). 3. Report progress if isatty(2) is 1. This changes progress reporting behaviour such that if both --progress and --quiet are specified, progress is reported. In two areas, the logic to determine whether to *not* show progress is changed to simply use the negation of transport->progress. This changes behaviour in some ways (see previous paragraph for details). Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24push: support multiple levels of verbosityLibravatar Tay Ray Chuan1-1/+0
Remove the flags TRANSPORT_PUSH_QUIET and TRANSPORT_PUSH_VERBOSE; use transport->verbose instead to determine verbosity for pushing. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-03Typofixes outside documentation areaLibravatar Junio C Hamano1-1/+1
begining -> beginning canonicalizations -> canonicalization comand -> command dewrapping -> unwrapping dirtyness -> dirtiness DISCLAMER -> DISCLAIMER explicitely -> explicitly feeded -> fed impiled -> implied madatory -> mandatory mimick -> mimic preceeding -> preceding reqeuest -> request substition -> substitution Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge branch 'js/exec-error-report'Libravatar Junio C Hamano1-4/+10
* js/exec-error-report: Improve error message when a transport helper was not found start_command: detect execvp failures early run-command: move wait_or_whine earlier start_command: report child process setup errors to the parent's stderr Conflicts: Makefile
2010-01-20Merge branch 'tr/http-push-ref-status'Libravatar Junio C Hamano1-8/+20
* tr/http-push-ref-status: transport-helper.c::push_refs(): emit "no refs" error message transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed transport.c::transport_push(): make ref status affect return value refactor ref status logic for pushing t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs t5541-http-push.sh: add tests for non-fast-forward pushes Conflicts: transport-helper.c
2010-01-17Merge branch 'tc/clone-v-progress'Libravatar Junio C Hamano1-1/+1
* tc/clone-v-progress: clone: use --progress to force progress reporting clone: set transport->verbose when -v/--verbose is used git-clone.txt: reword description of progress behaviour check stderr with isatty() instead of stdout when deciding to show progress Conflicts: transport.c
2010-01-12Improve error message when a transport helper was not foundLibravatar Ilari Liusvaara1-4/+10
Perviously, the error message was: git: 'remote-foo' is not a git-command. See 'git --help'. By not treating the transport helper as a git command, a more suitable error is reported: fatal: Unable to find remote helper for 'foo' Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-09transport-helper.c::push_refs(): emit "no refs" error messageLibravatar Tay Ray Chuan1-1/+4
Emit an error message when remote_refs is not set. This behaviour is consistent with that of builtin-send-pack.c and http-push.c. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-09transport-helper.c::push_refs(): ignore helper-reported status if ref is not ↵Libravatar Tay Ray Chuan1-0/+9
to be pushed If the status of a ref is REF_STATUS_NONE, the remote helper will not be told to push the ref (via a 'push' command). However, the remote helper may still act on these refs. If the helper does act on the ref, and prints a status for it, ignore the report (ie. don't overwrite the status of the ref with it, nor the message in the remote_status member) if the reported status is 'no match'. This allows the user to be alerted to more "interesting" ref statuses, like REF_STATUS_NONFASTFORWARD. Cc: Jeff King <peff@peff.net> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>