- 26 9月, 2015 1 次提交
-
-
由 Jeff King 提交于
The current callers only want to die when their transport is prohibited. But future callers want to query the mechanism without dying. Let's break out a few query functions, and also save the results in a static list so we don't have to re-parse for each query. Based-on-a-patch-by: NBlake Burkhart <bburky@bburky.com> Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 9月, 2015 1 次提交
-
-
由 Jeff King 提交于
If we are cloning an untrusted remote repository into a sandbox, we may also want to fetch remote submodules in order to get the complete view as intended by the other side. However, that opens us up to attacks where a malicious user gets us to clone something they would not otherwise have access to (this is not necessarily a problem by itself, but we may then act on the cloned contents in a way that exposes them to the attacker). Ideally such a setup would sandbox git entirely away from high-value items, but this is not always practical or easy to set up (e.g., OS network controls may block multiple protocols, and we would want to enable some but not others). We can help this case by providing a way to restrict particular protocols. We use a whitelist in the environment. This is more annoying to set up than a blacklist, but defaults to safety if the set of protocols git supports grows). If no whitelist is specified, we continue to default to allowing all protocols (this is an "unsafe" default, but since the minority of users will want this sandboxing effect, it is the only sensible one). A note on the tests: ideally these would all be in a single test file, but the git-daemon and httpd test infrastructure is an all-or-nothing proposition rather than a test-by-test prerequisite. By putting them all together, we would be unable to test the file-local code on machines without apache. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 1月, 2015 1 次提交
-
-
由 Ronnie Sahlberg 提交于
Add a command line argument to the git push command to request atomic pushes. Signed-off-by: NRonnie Sahlberg <sahlberg@google.com> Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 9月, 2014 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 11 12月, 2013 3 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 8月, 2013 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 23 7月, 2013 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 09 7月, 2013 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 19 6月, 2013 1 次提交
-
-
由 Phil Hord 提交于
Documentation and some comments still refer to files in builtin/ as 'builtin-*.[cho]'. Update these to show the correct location. Signed-off-by: NPhil Hord <hordp@cisco.com> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Assisted-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 5月, 2013 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 4月, 2013 1 次提交
-
-
由 Stefano Lattarini 提交于
Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: NStefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Acked-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 3月, 2013 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 25 1月, 2013 1 次提交
-
-
由 Junio 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: NJunio C Hamano <gitster@pobox.com>
-
- 19 1月, 2013 1 次提交
-
-
由 Aaron Schrab 提交于
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: NAaron Schrab <aaron@schrab.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 12月, 2012 2 次提交
-
-
由 Chris Rorvick 提交于
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: NChris Rorvick <chris@rorvick.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Chris 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: NChris Rorvick <chris@rorvick.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 10月, 2012 1 次提交
-
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJeff King <peff@peff.net>
-
- 15 9月, 2012 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 3月, 2012 1 次提交
-
-
由 Heiko Voigt 提交于
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: NFredrik Gustafsson <iveqy@iveqy.com> Mentored-by: NJens Lehmann <Jens.Lehmann@web.de> Mentored-by: NHeiko Voigt <hvoigt@hvoigt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 3月, 2012 1 次提交
-
-
由 Jeff King 提交于
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 f25950f3 (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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2012 1 次提交
-
-
由 Felipe Contreras 提交于
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: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 8月, 2011 1 次提交
-
-
由 Fredrik Gustafsson 提交于
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: NFredrik Gustafsson <iveqy@iveqy.com> Mentored-by: NJens Lehmann <Jens.Lehmann@web.de> Mentored-by: NHeiko Voigt <hvoigt@hvoigt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 5月, 2011 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 3月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com> Acked-by: NShawn O. Pearce <spearce@spearce.org>
-
- 14 10月, 2010 1 次提交
-
-
由 Ilari Liusvaara 提交于
This helper function copies bidirectional stream of data between stdin/stdout and specified file descriptors. Signed-off-by: NIlari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 2月, 2010 4 次提交
-
-
由 Tay Ray Chuan 提交于
Signed-off-by: NTay Ray Chuan <rctay89@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Tay Ray Chuan 提交于
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: NTay Ray Chuan <rctay89@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Tay Ray Chuan 提交于
Remove the flags TRANSPORT_PUSH_QUIET and TRANSPORT_PUSH_VERBOSE; use transport->verbose instead to determine verbosity for pushing. Signed-off-by: NTay Ray Chuan <rctay89@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Tay Ray Chuan 提交于
transport_set_verbosity() is now provided to transport users. Signed-off-by: NTay Ray Chuan <rctay89@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 2月, 2010 1 次提交
-
-
由 Michael Lukashov 提交于
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: NMichael Lukashov <michael.lukashov@gmail.com> Acked-by: NTay Ray Chuan <rctay89@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 2月, 2010 1 次提交
-
-
由 Tay Ray Chuan 提交于
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: NTay Ray Chuan <rctay89@gmail.com> Acked-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 1月, 2010 1 次提交
-
-
由 Ilari Liusvaara 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NIlari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 12月, 2009 1 次提交
-
-
由 Tay Ray Chuan 提交于
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: NTay Ray Chuan <rctay89@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 12月, 2009 1 次提交
-
-
由 Ilari Liusvaara 提交于
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: NIlari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 12月, 2009 2 次提交
-
-
由 Ilari Liusvaara 提交于
Add support for taking over transports that turn out to be smart. Signed-off-by: NIlari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ilari Liusvaara 提交于
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: NIlari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 11月, 2009 1 次提交
-
-
由 Daniel Barkalow 提交于
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: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NSverre Rabbelier <srabbelier@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 10月, 2009 1 次提交
-
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> CC: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-