summaryrefslogtreecommitdiff
path: root/transport.h
AgeCommit message (Collapse)AuthorFilesLines
2015-01-07push.c: add an --atomic argumentLibravatar Ronnie Sahlberg1-0/+1
Add a command line argument to the git push command to request atomic pushes. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-15push: the beginning of "git push --signed"Libravatar Junio C Hamano1-0/+5
While signed tags and commits assert that the objects thusly signed came from you, who signed these objects, there is not a good way to assert that you wanted to have a particular object at the tip of a particular branch. My signing v2.0.1 tag only means I want to call the version v2.0.1, and it does not mean I want to push it out to my 'master' branch---it is likely that I only want it in 'maint', so the signature on the object alone is insufficient. The only assurance to you that 'maint' points at what I wanted to place there comes from your trust on the hosting site and my authentication with it, which cannot easily audited later. Introduce a mechanism that allows you to sign a "push certificate" (for the lack of better name) every time you push, asserting that what object you are pushing to update which ref that used to point at what other object. Think of it as a cryptographic protection for ref updates, similar to signed tags/commits but working on an orthogonal axis. The basic flow based on this mechanism goes like this: 1. You push out your work with "git push --signed". 2. The sending side learns where the remote refs are as usual, together with what protocol extension the receiving end supports. If the receiving end does not advertise the protocol extension "push-cert", an attempt to "git push --signed" fails. Otherwise, a text file, that looks like the following, is prepared in core: certificate version 0.1 pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700 7339ca65... 21580ecb... refs/heads/master 3793ac56... 12850bec... refs/heads/next The file begins with a few header lines, which may grow as we gain more experience. The 'pusher' header records the name of the signer (the value of user.signingkey configuration variable, falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the certificate generation. After the header, a blank line follows, followed by a copy of the protocol message lines. Each line shows the old and the new object name at the tip of the ref this push tries to update, in the way identical to how the underlying "git push" protocol exchange tells the ref updates to the receiving end (by recording the "old" object name, the push certificate also protects against replaying). It is expected that new command packet types other than the old-new-refname kind will be included in push certificate in the same way as would appear in the plain vanilla command packets in unsigned pushes. The user then is asked to sign this push certificate using GPG, formatted in a way similar to how signed tag objects are signed, and the result is sent to the other side (i.e. receive-pack). In the protocol exchange, this step comes immediately before the sender tells what the result of the push should be, which in turn comes before it sends the pack data. 3. When the receiving end sees a push certificate, the certificate is written out as a blob. The pre-receive hook can learn about the certificate by checking GIT_PUSH_CERT environment variable, which, if present, tells the object name of this blob, and make the decision to allow or reject this push. Additionally, the post-receive hook can also look at the certificate, which may be a good place to log all the received certificates for later audits. Because a push certificate carry the same information as the usual command packets in the protocol exchange, we can omit the latter when a push certificate is in use and reduce the protocol overhead. This however is not included in this patch to make it easier to review (in other words, the series at this step should never be released without the remainder of the series, as it implements an interim protocol that will be incompatible with the final one). As such, the documentation update for the protocol is left out of this step. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10fetch: add --update-shallow to accept refs that update .git/shallowLibravatar Nguyễn Thái Ngọc Duy1-0/+4
The same steps are done as in when --update-shallow is not given. The only difference is we now add all shallow commits in "ours" and "theirs" to .git/shallow (aka "step 8"). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10clone: support remote shallow repositoryLibravatar Nguyễn Thái Ngọc Duy1-0/+6
Cloning from a shallow repository does not follow the "8 steps for new .git/shallow" because if it does we need to get through step 6 for all refs. That means commit walking down to the bottom. Instead the rule to create .git/shallow is simpler and, more importantly, cheap: if a shallow commit is found in the pack, it's probably used (i.e. reachable from some refs), so we add it. Others are dropped. One may notice this method seems flawed by the word "probably". A shallow commit may not be reachable from any refs at all if it's attached to an object island (a group of objects that are not reachable by any refs). If that object island is not complete, a new fetch request may send more objects to connect it to some ref. At that time, because we incorrectly installed the shallow commit in this island, the user will not see anything after that commit (fsck is still ok). This is not desired. Given that object islands are rare (C Git never sends such islands for security reasons) and do not really harm the repository integrity, a tradeoff is made to surprise the user occasionally but work faster everyday. A new option --strict could be added later that follows exactly the 8 steps. "git prune" can also learn to remove dangling objects _and_ the shallow commits that are attached to them from .git/shallow. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10transport.h: remove send_pack prototype, already defined in send-pack.hLibravatar Nguyễn Thái Ngọc Duy1-6/+0
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09Merge branch 'jc/transport-do-not-use-connect-twice-in-fetch'Libravatar Junio C Hamano1-0/+6
The auto-tag-following code in "git fetch" tries to reuse the same transport twice when the serving end does not cooperate and does not give tags that point to commits that are asked for as part of the primary transfer. Unfortunately, Git-aware transport helper interface is not designed to be used more than once, hence this does not work over smart-http transfer. * jc/transport-do-not-use-connect-twice-in-fetch: builtin/fetch.c: Fix a sparse warning fetch: work around "transport-take-over" hack fetch: refactor code that fetches leftover tags fetch: refactor code that prepares a transport fetch: rename file-scope global "transport" to "gtransport" t5802: add test for connect helper
2013-08-07fetch: work around "transport-take-over" hackLibravatar Junio C Hamano1-0/+6
A Git-aware "connect" transport allows the "transport_take_over" to redirect generic transport requests like fetch(), push_refs() and get_refs_list() to the native Git transport handling methods. The take-over process replaces transport->data with a fake data that these method implementations understand. While this hack works OK for a single request, it breaks when the transport needs to make more than one requests. transport->data that used to hold necessary information for the specific helper to work correctly is destroyed during the take-over process. One codepath that this matters is "git fetch" in auto-follow mode; when it does not get all the tags that ought to point at the history it got (which can be determined by looking at the peeled tags in the initial advertisement) from the primary transfer, it internally makes a second request to complete the fetch. Because "take-over" hack has already destroyed the data necessary to talk to the transport helper by the time this happens, the second request cannot make a request to the helper to make another connection to fetch these additional tags. Mark such a transport as "cannot_reuse", and use a separate transport to perform the backfill fetch in order to work around this breakage. Note that this problem does not manifest itself when running t5802, because our upload-pack gives you all the necessary auto-followed tags during the primary transfer. You would need to step through "git fetch" in a debugger, stop immediately after the primary transfer finishes and writes these auto-followed tags, remove the tag references and repack/prune the repository to convince the "find-non-local-tags" procedure that the primary transfer failed to give us all the necessary tags, and then let it continue, in order to trigger the bug in the secondary transfer this patch fixes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22push --force-with-lease: implement logic to populate old_sha1_expect[]Libravatar Junio C Hamano1-0/+4
This plugs the push_cas_option data collected by the command line option parser to the transport system with a new function apply_push_cas(), which is called after match_push_refs() has already been called. At this point, we know which remote we are talking to, and what remote refs we are going to update, so we can fill in the details that may have been missing from the command line, such as (1) what abbreviated refname the user gave us matches the actual refname at the remote; and (2) which remote-tracking branch in our local repository to read the value of the object to expect at the remote. to populate the old_sha1_expect[] field of each of the remote ref. As stated in the documentation, the use of remote-tracking branch as the default is a tentative one, and we may come up with a better logic as we gain experience. Still nobody uses this information, which is the topic of the next patch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-08cache.h: move remote/connect API out of itLibravatar Junio C Hamano1-0/+1
The definition of "struct ref" in "cache.h", a header file so central to the system, always confused me. This structure is not about the local ref used by sha1-name API to name local objects. It is what refspecs are expanded into, after finding out what refs the other side has, to define what refs are updated after object transfer succeeds to what values. It belongs to "remote.h" together with "struct refspec". While we are at it, also move the types and functions related to the Git transport connection to a new header file connect.h Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26Merge branch 'ph/builtin-srcs-are-in-subdir-these-days'Libravatar Junio C Hamano1-1/+1
* ph/builtin-srcs-are-in-subdir-these-days: fix "builtin-*" references to be "builtin/*"
2013-06-18fix "builtin-*" references to be "builtin/*"Libravatar Phil Hord1-1/+1
Documentation and some comments still refer to files in builtin/ as 'builtin-*.[cho]'. Update these to show the correct location. Signed-off-by: Phil Hord <hordp@cisco.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Assisted-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28clone: open a shortcut for connectivity checkLibravatar Nguyễn Thái Ngọc Duy1-0/+2
In order to make sure the cloned repository is good, we run "rev-list --objects --not --all $new_refs" on the repository. This is expensive on large repositories. This patch attempts to mitigate the impact in this special case. In the "good" clone case, we only have one pack. If all of the following are met, we can be sure that all objects reachable from the new refs exist, which is the intention of running "rev-list ...": - all refs point to an object in the pack - there are no dangling pointers in any object in the pack - no objects in the pack point to objects outside the pack The second and third checks can be done with the help of index-pack as a slight variation of --strict check (which introduces a new condition for the shortcut: pack transfer must be used and the number of objects large enough to call index-pack). The first is checked in check_everything_connected after we get an "ok" from index-pack. "index-pack + new checks" is still faster than the current "index-pack + rev-list", which is the whole point of this patch. If any of the conditions fail, we fall back to the good old but expensive "rev-list ..". In that case it's even more expensive because we have to pay for the new checks in index-pack. But that should only happen when the other side is either buggy or malicious. Cloning linux-2.6 over file:// before after real 3m25.693s 2m53.050s user 5m2.037s 4m42.396s sys 0m13.750s 0m16.574s A more realistic test with ssh:// over wireless before after real 11m26.629s 10m4.213s user 5m43.196s 5m19.444s sys 0m35.812s 0m37.630s This shortcut is not applied to shallow clones, partly because shallow clones should have no more objects than a usual fetch and the cost of rev-list is acceptable, partly to avoid dealing with corner cases when grafting is involved. This shortcut does not apply to unpack-objects code path either because the number of objects must be small in order to trigger that code path. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12Sync with 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Correct common spelling mistakes in comments and tests kwset: fix spelling in comments precompose-utf8: fix spelling of "want" in error message compat/nedmalloc: fix spelling in comments compat/regex: fix spelling and grammar in comments obstack: fix spelling of similar contrib/subtree: fix spelling of accidentally git-remote-mediawiki: spelling fixes doc: various spelling fixes fast-export: fix argument name in error messages Documentation: distinguish between ref and offset deltas in pack-format i18n: make the translation of -u advice in one go
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-03-25Merge branch 'jc/push-follow-tag'Libravatar Junio C Hamano1-0/+1
The new "--follow-tags" option tells "git push" to push relevant annotated tags when pushing branches out. * jc/push-follow-tag: push: --follow-tags commit.c: use clear_commit_marks_many() in in_merge_bases_many() commit.c: add in_merge_bases_many() commit.c: add clear_commit_marks_many()
2013-03-05push: --follow-tagsLibravatar Junio C Hamano1-0/+1
The new option "--follow-tags" tells "git push" to push annotated tags that are missing from the other side and that can be reached by the history that is otherwise pushed out. For example, if you are using the "simple", "current", or "upstream" push, you would ordinarily push the history leading to the commit at your current HEAD and nothing else. With this option, you would also push all annotated tags that can be reached from that commit to the other side. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-04Merge branch 'jc/push-reject-reasons'Libravatar Junio C Hamano1-0/+2
Improve error and advice messages given locally when "git push" refuses when it cannot compute fast-forwardness by separating these cases from the normal "not a fast-forward; merge first and push again" case. * jc/push-reject-reasons: push: finishing touches to explain REJECT_ALREADY_EXISTS better push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE push: further simplify the logic to assign rejection reason push: further clean up fields of "struct ref"
2013-01-24push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCELibravatar Junio C Hamano1-0/+2
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>
2013-01-18push: Add support for pre-push hooksLibravatar Aaron Schrab1-0/+1
Add support for a pre-push hook which can be used to determine if the set of refs to be pushed is suitable for the target repository. The hook is run with two arguments specifying the name and location of the destination repository. Information about what is to be pushed is provided by sending lines of the following form to the hook's standard input: <local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF If the hook exits with a non-zero status, the push will be aborted. This will allow the script to determine if the push is acceptable based on the target repository and branch(es), the commits which are to be pushed, and even the source branches in some cases. Signed-off-by: Aaron Schrab <aaron@schrab.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02push: add advice for rejected tag referenceLibravatar Chris Rorvick1-0/+1
Advising the user to fetch and merge only makes sense if the rejected reference is a branch. If none of the rejections are for branches, just tell the user the reference already exists. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02push: return reject reasons as a bitsetLibravatar Chris Rorvick1-4/+5
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 <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-29send-pack: move core code to libgit.aLibravatar Nguyễn Thái Ngọc Duy1-0/+5
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 <pclouds@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2012-09-14fetch: align per-ref summary report in UTF-8 localesLibravatar Nguyễn Thái Ngọc Duy1-0/+1
fetch does printf("%-*s", width, "foo") where "foo" can be a utf-8 string, but width is in bytes, not columns. For ASCII it's fine as one byte takes one column. For utf-8, this may result in misaligned ref summary table. Introduce gettext_width() function that returns the string length in columns (currently only supports utf-8 locales). Make the code use TRANSPORT_SUMMARY(x) where the length is compensated properly in non-English locales. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24Merge branch 'hv/submodule-recurse-push'Libravatar Junio C Hamano1-0/+1
"git push --recurse-submodules" learns to optionally look into the histories of submodules bound to the superproject and push them out. By Heiko Voigt * hv/submodule-recurse-push: push: teach --recurse-submodules the on-demand option Refactor submodule push check to use string list instead of integer Teach revision walking machinery to walk multiple times sequencially
2012-03-30push: teach --recurse-submodules the on-demand optionLibravatar Heiko Voigt1-0/+1
When using this option git will search for all submodules that have changed in the revisions to be send. It will then try to push the currently checked out branch of each submodule. This helps when a user has finished working on a change which involves submodules and just wants to push everything in one go. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-26clean up struct ref's nonfastforward fieldLibravatar Jeff King1-0/+2
Each ref structure contains a "nonfastforward" field which is set during push to show whether the ref rewound history. Originally this was a single bit, but it was changed in f25950f (push: Provide situational hints for non-fast-forward errors) to an enum differentiating a non-ff of the current branch versus another branch. However, we never actually set the member according to the enum values, nor did we ever read it expecting anything but a boolean value. But we did use the side effect of declaring the enum constants to store those values in a totally different integer variable. The code as-is isn't buggy, but the enum declaration inside "struct ref" is somewhat misleading. Let's convert nonfastforward back into a single bit, and then define the NON_FF_* constants closer to where they would be used (they are returned via the "int *nonfastforward" parameter to transport_push, so we can define them there). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-22push: add '--prune' optionLibravatar Felipe Contreras1-0/+1
When pushing groups of refs to a remote, there is no simple way to remove old refs that still exist at the remote that is no longer updated from us. This will allow us to remove such refs from the remote. With this change, running this command $ git push --prune remote refs/heads/*:refs/remotes/laptop/* removes refs/remotes/laptop/foo from the remote if we do not have branch "foo" locally anymore. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-20push: Don't push a repository with unpushed submodulesLibravatar Fredrik Gustafsson1-0/+1
When working with submodules it is easy to forget to push a submodule to the server but pushing a super-project that contains a commit for that submodule. The result is that the superproject points at a submodule commit that is not available on the server. This adds the option --recurse-submodules=check to push. When using this option git will check that all submodule commits that are about to be pushed are present on a remote of the submodule. To be able to use a combined diff, disabling a diff callback has been removed from combined-diff.c. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-19refactor refs_from_alternate_cb to allow passing extra dataLibravatar Jeff King1-1/+1
The foreach_alt_odb function triggers a callback for each alternate object db we have, with room for a single void pointer as data. Currently, we always call refs_from_alternate_cb as the callback function, and then pass another callback (to receive each ref individually) as the void pointer. This has two problems: 1. C technically forbids stuffing a function pointer into a "void *". In practice, this probably doesn't matter on any architectures git runs on, but it never hurts to follow the letter of the law. 2. There is no room for an extra data pointer. Indeed, the alternate_ref_fn that refs_from_alternate_cb calls takes a void* for data, but we always pass it NULL. Instead, let's properly stuff our function pointer into a data struct, which also leaves room for an extra caller-supplied data pointer. And to keep things simple for existing callers, let's make a for_each_alternate_ref function that takes care of creating the extra struct. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-17refs_from_alternate: helper to use refs from alternatesLibravatar Junio C Hamano1-0/+3
The receiving end of "git push" advertises the objects that the repository itself does not use, but are at the tips of refs in other repositories whose object databases are used as alternates for it. This helps it avoid having to receive (and the pusher having to send) objects that are already available to the receiving repository via the alternates mechanism. Tweak the helper function that implements this feature, and move it to transport.[ch] for future reuse by other programs. The additional test demonstrates how this optimization is helping "git push", and "git fetch" is ignorant about it. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Shawn O. Pearce <spearce@spearce.org>
2010-10-13Add bidirectional_transfer_loop()Libravatar Ilari Liusvaara1-0/+1
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-03-15Merge branch 'tc/transport-verbosity'Libravatar Junio C Hamano1-5/+11
* 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-03-02Merge branch 'ml/send-pack-transport-refactor'Libravatar Junio C Hamano1-0/+11
* ml/send-pack-transport-refactor: refactor duplicated code in builtin-send-pack.c and transport.c
2010-02-24transport: update flags to be in running orderLibravatar Tay Ray Chuan1-2/+2
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24transport->progress: use flag authoritativelyLibravatar Tay Ray Chuan1-2/+8
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-2/+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-24fetch: refactor verbosity option handling into transport.[ch]Libravatar Tay Ray Chuan1-0/+1
transport_set_verbosity() is now provided to transport users. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17refactor duplicated code in builtin-send-pack.c and transport.cLibravatar Michael Lukashov1-0/+11
The following functions are (almost) identical: verify_remote_names update_tracking_ref refs_pushed print_push_status Move common versions of these functions to transport.c and rename them, as suggested by Jeff King and Junio C Hamano. These functions have been removed entirely from builtin-send-pack.c, since they are only used internally by print_push_status(): print_ref_status status_abbrev print_ok_ref_status print_one_push_status Also, move #define SUMMARY_WIDTH to transport.h and rename it TRANSPORT_SUMMARY_WIDTH as it is used in builtin-fetch.c and transport.c Signed-off-by: Michael Lukashov <michael.lukashov@gmail.com> Acked-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-16transport: add got_remote_refs flagLibravatar Tay Ray Chuan1-0/+6
transport_get_remote_refs() in tranport.c checks transport->remote_refs to determine whether transport->get_refs_list() should be invoked. The logic is "if it is NULL, we haven't run ls-remote to find out yet". However, transport->remote_refs could still be NULL while cloning from an empty repository. This causes get_refs_list() to be run unnecessarily. Introduce a flag, transport->got_remote_refs, to more explicitly record if we have run transport->get_refs_list() already. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge branch 'il/push-set-upstream'Libravatar Junio C Hamano1-0/+1
* il/push-set-upstream: Add push --set-upstream Conflicts: transport.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-16Add push --set-upstreamLibravatar Ilari Liusvaara1-0/+1
Frequent complaint is lack of easy way to set up upstream (tracking) references for git pull to work as part of push command. So add switch --set-upstream (-u) to do just that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-28check stderr with isatty() instead of stdout when deciding to show progressLibravatar Tay Ray Chuan1-1/+1
Make transport code (viz. transport.c::fetch_refs_via_pack() and transport-helper.c::standard_options()) that decides to show progress check if stderr is a terminal, instead of stdout. After all, progress reports (via the API in progress.[ch]) are sent to stderr. Update the documentation for git-clone to say "standard error" as well. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-28Support remote archive from all smart transportsLibravatar Ilari Liusvaara1-0/+5
Previously, remote archive required internal (non remote-helper) smart transport. Extend the remote archive to also support smart transports implemented by remote helpers. Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-09Support taking over transportsLibravatar Ilari Liusvaara1-0/+2
Add support for taking over transports that turn out to be smart. Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-09Refactor git transport options parsingLibravatar Ilari Liusvaara1-0/+15
Refactor the transport options parsing so that protocols that aren't directly smart transports (file://, git://, ssh:// & co) can record the smart transport options for the case if it turns that transport can actually be smart. Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-06Merge branch 'master' into il/vcs-helperLibravatar Junio C Hamano1-1/+1
* master: (334 commits) bash: update 'git commit' completion Git 1.6.5.5 Fix diff -B/--dirstat miscounting of newly added contents reset: improve worktree safety valves Documentation: Avoid use of xmlto --stringparam archive: clarify description of path parameter rerere: don't segfault on failure to open rr-cache Prepare for 1.6.5.5 gitweb: Describe (possible) gitweb.js minification in gitweb/README Documentation: xmlto 0.0.18 does not know --stringparam Fix crasher on encountering SHA1-like non-note in notes tree t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-' t4201: use ISO8859-1 rather than ISO-8859-1 Git 1.6.5.4 Unconditionally set man.base.url.for.relative.links Documentation/Makefile: allow man.base.url.for.relative.link to be set from Make Git 1.6.6-rc1 git-pull.sh: Fix call to git-merge for new command format Prepare for 1.6.5.4 merge: do not add standard message when message is given with -m option ... Conflicts: Documentation/git-remote-helpers.txt Makefile builtin-ls-remote.c builtin-push.c transport-helper.c Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-17Allow fetch to modify refsLibravatar Daniel Barkalow1-2/+39
This allows the transport to use the null sha1 for a ref reported to be present in the remote repository to indicate that a ref exists but its actual value is presently unknown and will be set if the objects are fetched. Also adds documentation to the API to specify exactly what the methods should do and how they should interpret arguments. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-30fetch: Allow transport -v -v -v to set verbosity to 3Libravatar Shawn O. Pearce1-1/+1
Helpers might want a higher level of verbosity than just +1 (the porcelain default setting) and +2 (-v -v). Expand the field to allow verbosity in the range -1..3. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> CC: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13Merge branch 'db/vcs-helper'Libravatar Junio C Hamano1-0/+3
* db/vcs-helper: Makefile: remove remnant of separate http/https/ftp helpers Use a clearer style to issue commands to remote helpers Make the "traditionally-supported" URLs a special case Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible Makefile: do not link three copies of git-remote-* programs Makefile: git-http-fetch does not need expat http-fetch: Fix Makefile dependancies Add transport native helper executables to .gitignore git-http-fetch: not a builtin Use an external program to implement fetching with curl Add support for external programs for handling native fetches