From patchwork Sun Nov 7 22:55:23 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: 12607083 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 765C2C433F5 for ; Sun, 7 Nov 2021 22:56:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 504A0613A6 for ; Sun, 7 Nov 2021 22:56:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236017AbhKGW7E (ORCPT ); Sun, 7 Nov 2021 17:59:04 -0500 Received: from injection.crustytoothpaste.net ([192.241.140.119]:50786 "EHLO injection.crustytoothpaste.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236730AbhKGW6d (ORCPT ); Sun, 7 Nov 2021 17:58:33 -0500 Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b056:101:a6ae:7d13:8741:9028]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id D2B3F6077A; Sun, 7 Nov 2021 22:55:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1636325749; bh=H3ICVDYIlS8MAoJz/SzjR5wDxHfZiQPKji0K0JsnwFA=; 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=a+nF5Ly1czZmRllmC4IXsjVt7UiecZKFIPC7x3IcRzlFZ3no8F+1CPjto032JLOMr q9zI4pVrQh2HkogVYlUahWwFwUOGrtWuBIzcXedlcgvlsYNjQWEs1aD1hTfOUhhYzZ 1b4Ti9GJAII1zh37g8Nb+OoKhXNUA/nj6fgtbNGFVZ2SAKKRNwAgswczAttj81Vg8P A5ioy4s8Qwge8eM5g3/6egG8BPv0e12oVAWr9h6g8rqC2ANoyJLG97c5VTmeho4b7q WkGNmuvwFoDku+Ao/KG42y1j4We5h3j1z8qliThqfuBQB+Y4ulIpDgs5f5psWw9Eq2 qxA3OgMhXjM2qMZ1WN5+bicrgMGrkr6uJevPU+gpzSQXWeScC6wIeEHbbC2LRq+VGS J/1pLVkiH8VrLV8humBZfTaGoOEfL3n8CGAHZPT0Eb4KPkTwNYa1YgcP1nJ2cD/2Lg VoIHCt/W5L+6nB7/JOSin9GmLespx1JSJ3GsZ3hG+lv4/V4SYV9 From: "brian m. carlson" To: Cc: Jeff King , Johannes Schindelin , Bagas Sanjaya , Eric Sunshine , Junio C Hamano , Derrick Stolee Subject: [PATCH v2 1/3] gitfaq: add documentation on proxies Date: Sun, 7 Nov 2021 22:55:23 +0000 Message-Id: <20211107225525.431138-2-sandals@crustytoothpaste.net> X-Mailer: git-send-email 2.33.1.1089.g2158813163f In-Reply-To: <20211107225525.431138-1-sandals@crustytoothpaste.net> References: <20211107225525.431138-1-sandals@crustytoothpaste.net> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Many corporate environments and local systems have proxies in use. Note the situations in which proxies can be used and how to configure them. At the same time, note what standards a proxy must follow to work with Git. Explicitly call out certain classes that are known to routinely have problems reported various places online, including in the Git for Windows issue tracker and on Stack Overflow, and recommend against the use of such software. Signed-off-by: brian m. carlson --- Documentation/gitfaq.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt index 946691c153..5c21951f7b 100644 --- a/Documentation/gitfaq.txt +++ b/Documentation/gitfaq.txt @@ -241,6 +241,29 @@ 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]. +[[proxy]] +Can I use a proxy with Git?:: + Yes, Git supports the use of proxies. Git honors the standard `http_proxy`, + `https_proxy`, and `no_proxy` environment variables commonly used on Unix, and + it also can be configured with `http.proxy` and similar options for HTTPS (see + linkgit:git-config[1]). The `http.proxy` and related options can be + customized on a per-URL pattern basis. In addition, Git can in theory + function normally with transparent proxies that exist on the network. ++ +For SSH, Git can support a proxy using `core.gitproxy`. Commonly used tools +include `netcat` and `socat`. However, they must be configured not to exit when +seeing EOF on standard input, which usually means that `netcat` will require +`-q` and `socat` will require a timeout with something like `-t 10`. ++ +Note that in all cases, for Git to work properly, the proxy must be completely +transparent. The proxy cannot modify, tamper with, change, or buffer the +connection in any way, or Git will almost certainly fail to work. Note that +many proxies, including many TLS middleboxes, Windows antivirus and firewall +programs other than Windows Defender and Windows Firewall, and filtering proxies +fail to meet this standard, and as a result end up breaking Git. Because of the +many reports of problems, we recommend against the use of these classes of +software and devices. + Design ------ From patchwork Sun Nov 7 22:55:24 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: 12607089 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66186C4332F for ; Sun, 7 Nov 2021 22:56:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4666761458 for ; Sun, 7 Nov 2021 22:56:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236001AbhKGW7N (ORCPT ); Sun, 7 Nov 2021 17:59:13 -0500 Received: from injection.crustytoothpaste.net ([192.241.140.119]:50828 "EHLO injection.crustytoothpaste.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235989AbhKGW7D (ORCPT ); Sun, 7 Nov 2021 17:59:03 -0500 Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b056:101:a6ae:7d13:8741:9028]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 1F7CD60794; Sun, 7 Nov 2021 22:55:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1636325749; bh=mYh1xxhOyB2jHzGLgbO1JNyo+E17hYE/3lREk4ImlX0=; 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=QQmi+QAWJcex4qOferHV0xjdq3X8YR/U9oJPtPYx7s8Q/419OEvlT+/u2XWYZNooD mMDjGgtZRzEaYC7NCkmvcXbmwJkH6Io7WA3zvoGRBSHaJnZBXsc9WDdGkRFPmKu+RT j4WaEPzrUIs0gCKYvIQVxTt+pZG5iH2Jy8yiZIfnTW95pIVshu1YPDe2+Cn20Qo8bZ EfGuTDtRmoK9O7DpdeZ956g5wp62VB15OZG1buaFFgdDbkYKJdFV6iBgpiic5r9KI3 TKhxKNUKye0THZPffOqyvLOsiJ6mOGQNCTaOK9/hpT+JAI0Vqa9Up3Ha3pOEdddMdo iTpkS3YIkBuh7aEg7y/FTk0FaeNuM4igMreWJyZKb1I0GOzK3ZjW8MJcI8lbGFvxQQ UGeWE6ueCZjS2avyW7j8nqQlEKTVIsxgGqLBTD2wnqDFXlytPQmpKahCuYIFk8w4th g+TfCtTag+wC57QJXluL9NRnSJVxIT6KgPWfDwD/Qdo2r9gO7bw From: "brian m. carlson" To: Cc: Jeff King , Johannes Schindelin , Bagas Sanjaya , Eric Sunshine , Junio C Hamano , Derrick Stolee Subject: [PATCH v2 2/3] gitfaq: give advice on using eol attribute in gitattributes Date: Sun, 7 Nov 2021 22:55:24 +0000 Message-Id: <20211107225525.431138-3-sandals@crustytoothpaste.net> X-Mailer: git-send-email 2.33.1.1089.g2158813163f In-Reply-To: <20211107225525.431138-1-sandals@crustytoothpaste.net> References: <20211107225525.431138-1-sandals@crustytoothpaste.net> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org In the FAQ, we tell people how to use the text attribute, but we fail to explain what to do with the eol attribute. As we ourselves have noticed, most shell implementations do not care for carriage returns, and as such, people will practically always want them to use LF endings. Similar things can be said for batch files on Windows, except with CRLF endings. Since these are common things to have in a repository, let's help users make a good decision by recommending that they use the gitattributes file to correctly check out the endings. In addition, let's correct the cross-reference to this question, which originally referred to "the following entry", even though a new entry has been inserted in between. The cross-reference notation should prevent this from occurring and provide a link in formats, such as HTML, which support that. Signed-off-by: brian m. carlson --- Documentation/gitfaq.txt | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt index 5c21951f7b..ae1b526565 100644 --- a/Documentation/gitfaq.txt +++ b/Documentation/gitfaq.txt @@ -406,8 +406,9 @@ 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 -information about how to configure files as text or binary. +configuration option `core.eol` to `native` and see +<> +for information about how to configure files as text or binary. + You can also control this behavior with the `core.whitespace` setting if you don't wish to remove the carriage returns from your line endings. @@ -469,14 +470,25 @@ references, URLs, and hashes stored in the repository. + We also recommend setting a linkgit:gitattributes[5] file to explicitly mark which files are text and which are binary. If you want Git to guess, you can -set the attribute `text=auto`. For example, the following might be appropriate -in some projects: +set the attribute `text=auto`. ++ +With text files, Git will generally ensure that LF endings are used in the +repository, and will honor `core.autocrlf` and `core.eol` to decide what options +to use when checking files out. You can also override this by specifying a +particular line ending such as `eol=lf` or `eol=crlf` if those files must always +have that ending in the working tree (e.g., for functionality reasons). ++ +For example, the following might be appropriate in some projects: + ---- # By default, guess. * text=auto # Mark all C files as text. *.c text +# Ensure all shell files end up with LF endings and all batch files end up +# with CRLF endings in the working tree and both end up with LF in the repo. +*.sh text eol=lf +*.bat text eol=crlf # Mark all JPEG files as binary. *.jpg binary ---- From patchwork Sun Nov 7 22:55:25 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: 12607085 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8F79C433EF for ; Sun, 7 Nov 2021 22:56:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B39A5613B3 for ; Sun, 7 Nov 2021 22:56:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236769AbhKGW7F (ORCPT ); Sun, 7 Nov 2021 17:59:05 -0500 Received: from injection.crustytoothpaste.net ([192.241.140.119]:50818 "EHLO injection.crustytoothpaste.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236737AbhKGW6e (ORCPT ); Sun, 7 Nov 2021 17:58:34 -0500 Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b056:101:a6ae:7d13:8741:9028]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 62CEE60795; Sun, 7 Nov 2021 22:55:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1636325749; bh=XCEZBZmA0Ds5KGzlXn64kACTteNPnUN6ZCrW0Is9i2I=; 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=olkkJipyUX9wgxVXkN8ZYTlgMsrjHtxfg7tMUz4N68LUtz/l4/ppdVN5GpUYyQOJ5 j7sUSD8plYF+y7BzK84eTWZKAim5haXGKcAYRJ8BNeyXOT8kQGa/DmUIiwRNHIcDBQ JFcs8NoHB0zoFs72WqARH5iCWL5i6QLhL31KivvRQ/IkYNdJa9w3u+aXD6aHUL1YWl q8S+Z8Z55LpxlGEkGhxCYXBJV7NZefdBOzYI+/rx+pHtjSjnwWwwb4Bk+8wTjTJ1qC kdK6rqDe9PsJyYXVLbrYCX3SA3FAWVWmgd/Fz2SlpzciX1EEyspxWO75JmHSsLnNGG nxqmiJNDWcg+JY2kTPHNe/MWNco+yGjeY+orvc/ltRxx8IqbIzpTIvPN7gkMk5nQpk mI1oVhLCgDjvQ16sVptc6niyHKeIx7X6f6ougR9XjYQJk90xDNnYBpsNduHkgRXFQW DMSWmZLN05gpHnME4Qllr3HKtnyLR+kxjZzYE2gEBXQsiY1/oJG From: "brian m. carlson" To: Cc: Jeff King , Johannes Schindelin , Bagas Sanjaya , Eric Sunshine , Junio C Hamano , Derrick Stolee Subject: [PATCH v2 3/3] gitfaq: add entry about syncing working trees Date: Sun, 7 Nov 2021 22:55:25 +0000 Message-Id: <20211107225525.431138-4-sandals@crustytoothpaste.net> X-Mailer: git-send-email 2.33.1.1089.g2158813163f In-Reply-To: <20211107225525.431138-1-sandals@crustytoothpaste.net> References: <20211107225525.431138-1-sandals@crustytoothpaste.net> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Users very commonly want to sync their working tree with uncommitted changes across machines, often to carry across in-progress work or stashes. Despite this not being a recommended approach, users want to do it and are not dissuaded by suggestions not to, so let's recommend a sensible technique. The technique that many users are using is their preferred cloud syncing service, which is a bad idea. Users have reported problems where they end up with duplicate files that won't go away (with names like "file.c 2"), broken references, oddly named references that have date stamps appended to them, missing objects, and general corruption and data loss. That's because almost all of these tools sync file by file, which is a great technique if your project is a single word processing document or spreadsheet, but is utterly abysmal for Git repositories because they don't necessarily snapshot the entire repository correctly. They also tend to sync the files immediately instead of when the repository is quiescent, so writing multiple files, as occurs during a commit or a gc, can confuse the tools and lead to corruption. We know that the old standby, rsync, is up to the task, provided that the repository is quiescent, so let's suggest that and dissuade people from using cloud syncing tools. Let's tell people about common things they should be aware of before doing this and that this is still potentially risky. Additionally, let's tell people that Git's security model does not permit sharing working trees across users in case they planned to do that. While we'd still prefer users didn't try to do this, hopefully this will lead them in a safer direction. Signed-off-by: brian m. carlson --- Documentation/gitfaq.txt | 47 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 45 insertions(+), 2 deletions(-) diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt index ae1b526565..e5dab89d6c 100644 --- a/Documentation/gitfaq.txt +++ b/Documentation/gitfaq.txt @@ -83,8 +83,8 @@ Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`, which quotes the filename with spaces and specifies the `--nofork` option to avoid backgrounding the process. -Credentials ------------ +Credentials and Transfers +------------------------- [[http-credentials]] How do I specify my credentials when pushing over HTTP?:: @@ -185,6 +185,49 @@ 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`). +[[sync-working-tree]] +How do I sync a working tree across systems?:: + First, decide whether you want to do this at all. Git usually works better + when you push or pull your work using the typical `git push` and `git fetch` + commands and isn't designed to share a working tree across systems. This is + potentially risky and in some cases can cause repository corruption or data + loss. ++ +Usually, doing so will cause `git status` to need to re-read every file in the +working tree. Additionally, Git's security model does not permit sharing a +working tree across untrusted users, so it is only safe to sync a working tree +if it will only be used by a single user across all machines. ++ +It is important not to use a cloud syncing service to sync any portion of a Git +repository, since this can cause corruption, such as missing objects, changed +or added files, broken refs, and a wide variety of other corruption. These +services tend to sync file by file and don't understand the structure of a Git +repository. This is especially bad if they sync the repository in the middle of +it being updated, since that is very likely to cause incomplete or partial +updates and therefore data loss. ++ +Therefore, it's better to push your work to either the other system or a central +server using the normal push and pull mechanism. However, this doesn't always +preserve important data, like stashes, so some people prefer to share a working +tree across systems. ++ +If you do this, the recommended approach is to use `rsync -a --delete-after` +(ideally with an encrypted connection such as with `ssh`) on the root of +repository. You should ensure several things when you do this: ++ +* There are no additional worktrees enabled for your repository. +* You are not using a separate Git directory outside of your repository root. +* You are comfortable with the destination directory being an exact copy of the + source directory, _deleting any data that is already there_. +* The repository is in a quiescent state for the duration of the transfer (that + is, no operations of any sort are taking place on it, including background + operations like `git gc` and operations invoked by your editor). ++ +Be aware that even with these recommendations, syncing in this way has some risk +since it bypasses Git's normal integrity checking for repositories, so having +backups is advised. You may also with to do a `git fsck` to verify the +integrity of your data on the destination system after syncing. + Common Issues -------------