From patchwork Sat Feb 27 19:18:10 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "brian m. carlson" X-Patchwork-Id: 12107915 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54D6BC433DB for ; Sat, 27 Feb 2021 19:21:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 23CB164E56 for ; Sat, 27 Feb 2021 19:21:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230282AbhB0TVq (ORCPT ); Sat, 27 Feb 2021 14:21:46 -0500 Received: from injection.crustytoothpaste.net ([192.241.140.119]:58942 "EHLO injection.crustytoothpaste.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230336AbhB0TUw (ORCPT ); Sat, 27 Feb 2021 14:20:52 -0500 Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 9FFE860DF5; Sat, 27 Feb 2021 19:19:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614453574; bh=GcOohfjKp17jqputF2pT1ge5wxxZVRtAELmP78xupv8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Reply-To: Subject:Date:To:CC:Resent-Date:Resent-From:Resent-To:Resent-Cc: In-Reply-To:References:Content-Type:Content-Disposition; b=X3O2aXlZIuzNs3lynHQRvG2Q1UZV0PyIoWK+VqGYSc6jMDNBQwyffHlQZu4avY3oL 4E3tAdXd4XUDPHLIIub6g26SfwmQIcPY/PObUKJ6+DjtFquAbyueYx2veVysN5G3lX YZMBt3qW3aWrxz3Ie1OgOvYHbv7ejg7ngR0zXb27CQgjyovFCxkwOKtA1rhR1cPQpq /dZr0aoAeIAP4b6cO5HblPrPRsN+vikaV6lsL2mlXypiBlEYdRW/Xf6s2InRDkUGE4 3dXEgZEx1chIkQ9v+uByMgUYJ1ivhdrphW1oYERknMyZPHkmUjq8t9RcPeMzDqgtTl DHiJvQVAXmJiuB5KmobOxBJaxLRopSUeHwSjV45iqrWqofP8mpmUEs0wJgB/3IS3Jw /tHGSQxabJszTkPT/HbKuOdlssZu2HWXG3DxXqRKBk+VkHi+l09E/R4zF5tbCUmkLG /0oxUe06HJ4yd1Yqid8XlHQBhDJbbjrc3KBe846SYZyuuyJaVZo From: "brian m. carlson" To: Cc: Emily Shaffer , Johannes Schindelin Subject: [PATCH 1/4] docs: add a question on syncing repositories to the FAQ Date: Sat, 27 Feb 2021 19:18:10 +0000 Message-Id: <20210227191813.96148-2-sandals@crustytoothpaste.net> X-Mailer: git-send-email 2.30.1.721.g45526154a5 In-Reply-To: <20210227191813.96148-1-sandals@crustytoothpaste.net> References: <20210227191813.96148-1-sandals@crustytoothpaste.net> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org It is very common that users want to transport repositories with working trees across machines. While this is not recommended, many users do it anyway and moreover, do it using cloud syncing services, which often corrupt their data. The results of such are often seen in tales of woe on common user question fora. Let's tell users what we recommend they do in this circumstance and how to do it safely. Warn them about the dangers of untrusted working trees and the downsides of index refreshes, as well as the problems with cloud syncing services. Signed-off-by: brian m. carlson --- Documentation/gitfaq.txt | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt index afdaeab850..042b11e88a 100644 --- a/Documentation/gitfaq.txt +++ b/Documentation/gitfaq.txt @@ -241,6 +241,45 @@ How do I know if I want to do a fetch or a pull?:: ignore the upstream changes. A pull consists of a fetch followed immediately by either a merge or rebase. See linkgit:git-pull[1]. +[[syncing-across-computers]] +How do I sync a Git repository across multiple computers, VMs, or operating systems?:: + The best way to sync a repository across computers is by pushing and fetching. + This uses the native Git mechanisms to transport data efficiently and is the + easiest and best way to move data across machines. If the machines aren't + connected by a network, you can use `git bundle` to create a file with your + changes and then fetch or pull them from the file on the remote machine. + Pushing and fetching are also the only secure ways to interact with a + repository you don't own or trust. ++ +However, sometimes people want to sync a repository with a working tree across +machines. While this isn't recommended, it can be done with `rsync` (usually +over an SSH connection), but only when the repository is completely idle (that +is, no processes, including `git gc`, are modifying it at all). If `rsync` +isn't available, you can use `tar` to create a tar archive of the repository and +copy it to another machine. Zip files shouldn't be used due to their poor +support for permissions and symbolic links. ++ +You may also use a shared file system between the two machines that is POSIX +compliant, such as SSHFS (SFTP) or NFSv4. If you are using SFTP for this +purpose, the server should support fsync and POSIX renames (OpenSSH does). File +systems that don't provide POSIX semantics, such as DAV mounts, shouldn't be +used. ++ +Note that you must not work with untrusted working trees, since it's trivial +for an attacker to set configuration options that will cause arbitrary code to +be executed on your machine. Also, in almost all cases when sharing a working +tree across machines, Git will need to re-read all files the next time you run +`git status` or otherwise refresh the index, which can be slow. This generally +can't be avoided and is part of the reason why sharing a working tree isn't +recommended. ++ +In no circumstances should you share a working tree or bare repository using a +cloud syncing service or store it in a directory managed by such a service. +Such services sync file by file and don't maintain the invariants required for +repository integrity; in addition, they can cause files to be added, removed, or +duplicated unexpectedly. If you must use one of these services, use it to store +the repository in a tar archive instead. + Merging and Rebasing -------------------- From patchwork Sat Feb 27 19:18:11 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "brian m. carlson" X-Patchwork-Id: 12107919 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0132C433E0 for ; Sat, 27 Feb 2021 19:22:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B9C2E64E56 for ; Sat, 27 Feb 2021 19:22:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230361AbhB0TWt (ORCPT ); Sat, 27 Feb 2021 14:22:49 -0500 Received: from injection.crustytoothpaste.net ([192.241.140.119]:58970 "EHLO injection.crustytoothpaste.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230355AbhB0TVA (ORCPT ); Sat, 27 Feb 2021 14:21:00 -0500 Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 291E560DF6; Sat, 27 Feb 2021 19:19:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614453574; bh=bJurNQ09ftEn7n+GJ9ZWr+ugrZN+esb6+7mQoM4FRuA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Reply-To: Subject:Date:To:CC:Resent-Date:Resent-From:Resent-To:Resent-Cc: In-Reply-To:References:Content-Type:Content-Disposition; b=ldvZVEpSnI5iP0ImKbldbPXITqgd0HYhlTvFRF/0NYwFiIt3ZDMJYTDcGLg11oM72 2isf5teGNFMuluVwDUCeH7WEw6HRyeu0PArjbUNO+IJKNNy3yb//I+JJ267A7TZLZe pVnBAMeTCm7+MwYuvVBrMm3dsRfSsunxUBbPfM5nf7+BpEKPbiORS6xoyuZsPzdk6p IgzslyIHTxaDhNXZrD6mPAncIGYIuDMu7ilTh2rs4U3V6kQw51Re31W3wA6Z6CFsgC QmAulG7TM5ncjKoIgpLS5t7N4ezCCV4iAAaPGTLLtlxZV597fYwAEIEClwfWdeQZVQ hjhJOza6HV2bRWXlkJE1yIFDwlldVX3j+tXUf30sWN4zVc2QIHG+KMI3qqII1gIowz 6cv990+VF104HwuzfsPPXtjZLKDLUEBD5ztFyzhwLxVsvkQC+8a27+rLdLPdc8Pkvj 28GYpte3PUZ7Ev2gB7U9KnFNdKFM/KPeCyfJHZoLgxMWsAFuojQ From: "brian m. carlson" To: Cc: Emily Shaffer , Johannes Schindelin Subject: [PATCH 2/4] docs: add line ending configuration article to FAQ Date: Sat, 27 Feb 2021 19:18:11 +0000 Message-Id: <20210227191813.96148-3-sandals@crustytoothpaste.net> X-Mailer: git-send-email 2.30.1.721.g45526154a5 In-Reply-To: <20210227191813.96148-1-sandals@crustytoothpaste.net> References: <20210227191813.96148-1-sandals@crustytoothpaste.net> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org A common source of problems when working across projects is getting line endings to work in a consistent way. Let's explain to users how to configure their line endings such that they're automatically converted using the .gitattributes file. Update a reference to an incorrect FAQ entry by referring to the previous entry instead of the following one. Signed-off-by: brian m. carlson --- Documentation/gitfaq.txt | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt index 042b11e88a..a132f66032 100644 --- a/Documentation/gitfaq.txt +++ b/Documentation/gitfaq.txt @@ -387,6 +387,41 @@ repository will apply to all users of the repository. See the following entry for information about normalizing line endings as well, and see linkgit:gitattributes[5] for more information about attribute files. +[[line-ending-gitattributes]] +How do I fix my line endings to work well across platforms?:: + The best way to do this is to ask Git to perform automatic line ending + conversion in your repository such that it always stores LF (Unix) line + endings in the repository and checks them out to the user's preferred endings. + This is done using the `text` attribute in the `.gitattributes` file in the + root of your repository. If you want to use the built-in heuristic to + determine text files, you can write this: ++ +---- +* text=auto +---- ++ +If you have certain files that must always use specific line endings when +checked out, such as shell scripts, or PowerShell files, you can specifically +specify the line endings to be used, and you can also specifically mark some +files as not wanting line-ending conversion (`-text`): ++ +---- +*.sh text eol=lf +*.ps1 text eol=crlf +*.jpg -text +---- ++ +When you're done making these changes to the `.gitattributes` file, run `git add +--renormalize .` and then commit. This will make sure that the files in the +repository are properly stored with LF endings. ++ +Using this approach means that each developer can choose the line endings that +are best for their environment while keeping the repository consistent, avoiding +needless changes in the repository based on differing line endings, and allowing +tools like `git diff` to not display spurious whitespace errors. ++ +See linkgit:gitattributes[5] for more information about attribute files. + [[windows-diff-control-m]] I'm on Windows and git diff shows my files as having a `^M` at the end.:: By default, Git expects files to be stored with Unix line endings. As such, @@ -396,7 +431,7 @@ I'm on Windows and git diff shows my files as having a `^M` at the end.:: + You can store the files in the repository with Unix line endings and convert them automatically to your platform's line endings. To do that, set the -configuration option `core.eol` to `native` and see the following entry for +configuration option `core.eol` to `native` and see the previous entry for information about how to configure files as text or binary. + You can also control this behavior with the `core.whitespace` setting if you From patchwork Sat Feb 27 19:18:12 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "brian m. carlson" X-Patchwork-Id: 12107913 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1516C433E0 for ; Sat, 27 Feb 2021 19:21:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8708C64E4B for ; Sat, 27 Feb 2021 19:21:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230113AbhB0TVj (ORCPT ); Sat, 27 Feb 2021 14:21:39 -0500 Received: from injection.crustytoothpaste.net ([192.241.140.119]:58954 "EHLO injection.crustytoothpaste.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230345AbhB0TUv (ORCPT ); Sat, 27 Feb 2021 14:20:51 -0500 Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id A5E2960DF7; Sat, 27 Feb 2021 19:19:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614453575; bh=Sbfqyfi35Lj6G24df1jJJ9Ny6qMB9s8Itoycx8KqR24=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Reply-To: Subject:Date:To:CC:Resent-Date:Resent-From:Resent-To:Resent-Cc: In-Reply-To:References:Content-Type:Content-Disposition; b=b5t80yvZZ3gF6Fx3iaK7E2lI3zNIub23A1WoCuq3oS2tn2SJ3sYjQ7p2qVZH1OsOb 1eV5Uk+rI+dQmxwO3jcrz9HgSzCrsTaJvCf4NxCqcJFTeeBJ10/Sda2taFOQuEgtjR PYxkaxjHvPwnnxHu6h5HGV/CO09pQOr1tA/7mU/Jh3ZCujIanDl2iFH2RlWsga4aKv ufzdnY3ZKWuIlp7Kjakg0wvRGmwMG1QaS0zT9zk51JSjvdA85XzxH6fP24IM5IAwU8 PhuGrFVAPRTKPAxCAq/Z36WIYBDQvSsV6jdHuHqoU3YP5Y5sE5HBpyvd6aU+LIrEo6 EJOj7MPTHbbpXETaFHTeraQ2Fzo3lFnzGnH9fZyFZ/ZMOOMWQ+XE79Utzo67xvMp2j pbi0sopr5h7KLQcvhDgXb28ocu/Mv9WBvcYhkqB+9JjTKvs0LYjmcwoIBwKu+cQQY9 XYywObIdltV4Sc6ueIE4+reTlVf5u6ulLIjhhyWm/0GcAMUPFxR From: "brian m. carlson" To: Cc: Emily Shaffer , Johannes Schindelin Subject: [PATCH 3/4] docs: add a FAQ section on push and fetch problems Date: Sat, 27 Feb 2021 19:18:12 +0000 Message-Id: <20210227191813.96148-4-sandals@crustytoothpaste.net> X-Mailer: git-send-email 2.30.1.721.g45526154a5 In-Reply-To: <20210227191813.96148-1-sandals@crustytoothpaste.net> References: <20210227191813.96148-1-sandals@crustytoothpaste.net> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org There are a lot of questions on the Internet about common problems with fetching and pushing. Roughly, the vast majority of these problems are when using HTTP and involve HTTP/2 streams, certain HTTP errors, or connections which are interrupted. This latter case is especially common on Windows where non-default antivirus and firewall software frequently tampers with connections in undesirable ways. Let's add some FAQ entries explaining what is happening and how to troubleshoot and solve these problems. When discussing network connection issues, explicitly call out TLS man-in-the-middle devices, proxies, antivirus programs, and firewall applications, which are the cause of most of these problems, and encourage users to report these programs as broken. Since many sites offer both HTTPS and SSH, suggest using SSH, which is often not intercepted, as a good way to work around these problems. Signed-off-by: brian m. carlson --- Documentation/gitfaq.txt | 100 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt index a132f66032..fde54d2664 100644 --- a/Documentation/gitfaq.txt +++ b/Documentation/gitfaq.txt @@ -185,6 +185,106 @@ Then, you can adjust your push URL to use `git@example_author` or `git@example_committer` instead of `git@example.org` (e.g., `git remote set-url git@example_author:org1/project1.git`). +Problems Fetching and Pushing +----------------------------- + +[[remote-connection-http-2-stream-error]] +Why do I get an error about an HTTP/2 stream not being closed cleanly?:: + Sometimes when pushing or fetching over HTTP, users see a message such as "RPC + failed; curl 92 HTTP/2 stream 0 was not closed cleanly". This message + indicates that Git is using HTTP/2, a recent version of the HTTP protocol, and + that the remote server, or a middlebox, such as a proxy, TLS middlebox, + antivirus, or firewall, failed to speak the protocol correctly and thus the + connection was interrupted. ++ +In such a case, the software causing the problem is buggy and will likely be +broken with a wide variety of web browsers and other HTTP-using applications. +The best thing to do is contact the responsible party to get the software fixed. ++ +If that isn't possible, you can set the `http.version` option to `HTTP/1.1`, +which will force the use of an older version of HTTP. This should allow Git to +function with this broken software or device. If the remote server supports +SSH, you may wish to try switching to SSH instead. + +[[remote-connection-http-411]] +Why do I get an error about an HTTP 411 status?:: + Sometimes users see error messages when pushing that refer to HTTP status 411, + such as "RPC failed; result=22, HTTP code = 411." This status means that the + server or a machine in the middle, such as a proxy, TLS middlebox, antivirus, + firewall, or other middlebox, refuses to accept a streaming data connection. ++ +When pushing or fetching over HTTP, Git normally uses a small buffer and, if the +data is large, uses HTTP 1.1 chunked transfer encoding or HTTP 2 streaming to +send the data without a defined size. This is useful because it allows a push +or fetch to start much faster and therefore complete much faster. This type of +streaming has been standardized since 1999 and is well understood, and all +modern software should be capable of supporting it. ++ +However, in this case, the remote server or middlebox is misconfigured and does +not correctly support this. The best thing to do is contact the responsible +party and ask them to fix the server or middlebox, since this misconfiguration +can affect many pieces of software, some of which will simply not function at +all in this environment. ++ +If the remote server supports SSH, you may wish to try using SSH instead. If +that is not possible, you can set `http.postBuffer` to a larger value as a +workaround. This is one of the few times when that option is useful, but note +<> that doing so will increase +the memory usage for every push, no matter how small, and will not be able to +handle pushes of arbitrary sizes, so fixing the broken server or device or +switching to SSH is preferable in almost all cases. + +[[remote-connection-reset]] +Why do I get errors that the connection was reset?:: + When pushing or fetching, sometimes users see problems where the connection + was reset. Common symptoms of this problem include (but are not limited to) + messages like the following: ++ +* RPC failed; curl 56 OpenSSL SSL_read: Connection was reset, errno 10054 +* RPC failed; curl 55 SSL_write() returned SYSCALL, errno = 10053 +* RPC failed; curl 56 LibreSSL SSL_read: SSL_ERROR_SYSCALL, errno 60 +* RPC failed; result=56, HTTP code = 200 +* RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection was non-properly terminated. ++ +These messages, and almost every message with a libcurl error code of 55 or 56, +essentially mean that the network connection between Git and the remote server +was terminated unexpectedly. This can be caused by any sort of generic network +problem, such as packet loss or an unstable connection. Sometimes users also +see it when connected to a VPN if the connection over the VPN is unstable. In +such a case, disabling the VPN or switching to a different connection may help +the problem, or sending or receiving less data may work around the problem. ++ +This may also be caused by devices or software in the middle of the connection +which attempt to inspect the data. For example, if you're on a network which +uses a TLS middlebox or a proxy, these devices may attempt to inspect the data +and terminate the connection if the data is too large for them to handle or if +they mistakenly think it is malicious, offensive, inappropriate, or otherwise +unacceptable. To test if this is the problem, try using a different network +where these devices are not enabled, or contact your network administrator and +report the problem to them. ++ +On Windows, and to a lesser extent on other platforms, antivirus, firewall, or +network monitoring software that is not the default (on Windows, something other +than Windows Defender and Windows Firewall) can intercept network connections +and cause the same problems as the devices mentioned above. This may also +happen when using Git under the Windows Subsystem for Linux with such software. +To test if this is the problem, remove the non-default software completely and +restart your computer. Some such software does not disable the broken +functionality properly when it is set to disabled and so removing the software +is the only way to perform the test. If this is the problem, use the default +software instead, report the problem to the software vendor, or contact your +network administrator and report the problem to them. ++ +If you are using HTTPS and the remote server supports SSH, you may wish to try +using SSH instead. ++ +Note that in all these cases, this is not a problem in Git, but a problem with +the network or the devices and software managing it. Some parties mistakenly +recommend adjusting the `http.postBuffer` setting to work around this, but +<> for why that usually doesn't work, and +even when it does work, indicates a defect in the network or software such as +one mentioned above in this answer. + Common Issues ------------- From patchwork Sat Feb 27 19:18:13 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "brian m. carlson" X-Patchwork-Id: 12107921 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA087C433DB for ; Sat, 27 Feb 2021 19:23:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7FC8C64E4B for ; Sat, 27 Feb 2021 19:23:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230370AbhB0TXF (ORCPT ); Sat, 27 Feb 2021 14:23:05 -0500 Received: from injection.crustytoothpaste.net ([192.241.140.119]:58976 "EHLO injection.crustytoothpaste.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230351AbhB0TU6 (ORCPT ); Sat, 27 Feb 2021 14:20:58 -0500 Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 2DA4E60DF8; Sat, 27 Feb 2021 19:19:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614453575; bh=DnrvJ7AZdwIF0zB28lpZFqg6f6QOcLye/o2yFnVTHgI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Reply-To: Subject:Date:To:CC:Resent-Date:Resent-From:Resent-To:Resent-Cc: In-Reply-To:References:Content-Type:Content-Disposition; b=XT9m6F0pbdfyx+NgRWRvXdDOLLG9WuneYRJYMkv0A+C7Mte5gthUCCcsrKeA5vkLE KyiLjcDgQXBsGAqlJA4IH4A/BHJR2pv6MmnfZGS3+bXwlBB5DkqFhFyQkNwVQvILOM vTCX27dvVkb77y4AeLk8jLuHUXp6202eXkeWtY+oYUp9/rk/bvdh5qf5sxXpCv2sV/ tByPBDh41JwAHO+F23R+R2XhDOP6k4osRHXYNYRxXErdIBhLupjiH4Bvfh8QT5nu6A G/mcU6kZJET6HHfRA7Cy7twDNjwgr86JumtbU0ToUYqXch7LuB5g0VxbMQCLNrujEq qWH5afiDOHUOLYNYGmTLM7Nh5NSAqIJk+JQjNNEwh47Y/5wU5jjRjOFCfaH4maSojF /ez3H37cjzXRCWCuUxjRnP/IXPgDwY4cGAKkQMS6z/agg40TrmD0kfdaGau8+nVjxL zAQrZ7aQYTrjf+UeEVyZI8VY4NEFn8C1nqK0bEAH4Wyjkz8iZnw From: "brian m. carlson" To: Cc: Emily Shaffer , Johannes Schindelin Subject: [PATCH 4/4] docs: note that archives are not stable Date: Sat, 27 Feb 2021 19:18:13 +0000 Message-Id: <20210227191813.96148-5-sandals@crustytoothpaste.net> X-Mailer: git-send-email 2.30.1.721.g45526154a5 In-Reply-To: <20210227191813.96148-1-sandals@crustytoothpaste.net> References: <20210227191813.96148-1-sandals@crustytoothpaste.net> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org We have in the past told users on the list that git archive does not necessarily produce stable archives, but we've never explicitly documented this. Unfortunately, we've had people in the past who have relied on the relative stability of our archives to their detriment and then had breakage occur. Let's tell people that we don't guarantee stable archives so that they can make good choices about how they structure their tooling and don't end up with problems if we need to change archives later. Signed-off-by: brian m. carlson --- Documentation/git-archive.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt index 9f8172828d..1f126cbdcc 100644 --- a/Documentation/git-archive.txt +++ b/Documentation/git-archive.txt @@ -30,6 +30,9 @@ extended pax header if the tar format is used; it can be extracted using 'git get-tar-commit-id'. In ZIP files it is stored as a file comment. +The output of 'git archive' is not guaranteed to be stable and may change +between versions. + OPTIONS -------