{"thread":{"id":"56743","subject":"[PATCH 0/4] Additional FAQ entries","startedAt":"2021-10-20T01:06:34Z","lastAt":"2021-10-25T10:44:11Z","messageCount":30,"participants":["brian m. carlson","Eric Sunshine","Bagas Sanjaya","Ævar Arnfjörð Bjarmason","Johannes Schindelin","Philip Oakley","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"439073","messageId":"20211020010624.675562-1-sandals@crustytoothpaste.net","threadId":"56743","inReplyTo":null,"subject":"[PATCH 0/4] Additional FAQ entries","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T01:06:19Z","receivedAt":"2021-10-20T01:06:34Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"This series introduces some additional Git FAQ entries on various\ntopics. They are all things I've seen in my professional life or on\nStack Overflow, and I tire of repeating myself, so I've written\ndocumentation.\n\nThe first covers monorepos. It tries to strike a neutral tone and\nindicate that we're improving support for them, but it does note that\nmany large users still run into scale problems, especially at a point\nwhere it's inconvenient to change[0]. I do frequently see these problems\non some scale, so my hope is that we can make users consider this case\ncarefully. I have mentioned only scalability features which are\nreleased and reasonably mature, but if I've missed any that I should\nhave mentioned, please let me know, since I don't always follow the list\nas closely as I should.\n\nThe second covers proxies, in the generic sense of that word. It\ninstructs users how to use an HTTP proxy intentionally, and it also\nnotes that any proxy which buffers or tampers with the data will break\nGit. I frequently see users with TLS middleboxes or antivirus software\nother than the Windows default with breakage on Stack Overflow[1], and\nwe see them occasionally on the list as well. Because these tools are\nknown to cause both functionality and security problems, both for Git\nand in general[2][3][4], we explicitly recommend against them here. I\nam happy to provide additional citations to Project Zero, various bug\nreports, security experts, and the cryptographic literature if folks\nhave doubts about whether this is the right approach.\n\nThe third should be relatively uncontroversial. We discuss using eol\nattributes in gitattributes, which we had neglected to cover before, and\nillustrate their utility. In addition, we fix a reference.\n\nThe fourth and final patch covers syncing working trees. An earlier\nversion of this patch has come up on the list before and I had never\nsent a rerolled version. I realize that we don't love that people want\nto do this, but users are currently using cloud syncing services and\nexperiencing data loss, so I figured we'd better tell them how to do it\nas safely as they can so they stop losing data.\n\nI realize that folks are busy with the Contributor Summit and other\nthings, and so of course reviews may be delayed. I've tried to pick\npeople who I think will have relevant interest in each of these areas,\nbut of course feedback from anyone is welcome.\n\n[0] For instance, the Windows repo.\n[1] In addition to users for whom SSH \"magically\" works when HTTPS does\n not, many of which are likely the same issue.\n[2] https://robert.ocallahan.org/2017/01/disable-your-antivirus-software-except.html\n[3] https://twitter.com/parityzero/status/826489070310207489\n[4] https://groups.google.com/g/mozilla.dev.platform/c/Bh8U0DLHrCc\n\nbrian m. carlson (4):\n gitfaq: add advice on monorepos\n gitfaq: add documentation on proxies\n gitfaq: give advice on using eol attribute in gitattributes\n gitfaq: add entry about syncing working trees\n\n Documentation/gitfaq.txt | 107 ++++++++++++++++++++++++++++++++++++---\n 1 file changed, 101 insertions(+), 6 deletions(-)\n\n"},{"id":"439074","messageId":"20211020010624.675562-4-sandals@crustytoothpaste.net","threadId":"56743","inReplyTo":"20211020010624.675562-1-sandals@crustytoothpaste.net","subject":"[PATCH 3/4] gitfaq: give advice on using eol attribute in gitattributes","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T01:06:22Z","receivedAt":"2021-10-20T01:06:35Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"In the FAQ, we tell people how to use the text attribute, but we fail to\nexplain what to do with the eol attribute. As we ourselves have\nnoticed, most shell implementations do not care for carriage returns,\nand as such, people will practically always want them to use LF endings.\nSimilar things can be said for batch files on Windows, except with CRLF\nendings.\n\nSince these are common things to have in a repository, let's help users\nmake a good decision by recommending that they use the gitattributes\nfile to correctly check out the endings.\n\nIn addition, let's correct the cross-reference to this question, which\noriginally referred to \"the following entry\", even though a new entry\nhas been inserted in between. The cross-reference notation should\nprevent this from occurring and provide a link in formats, such as HTML,\nwhich support that.\n\nSigned-off-by: brian m. carlson \n---\n Documentation/gitfaq.txt | 20 ++++++++++++++++----\n 1 file changed, 16 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\nindex abc0f62e6c..85ac99c7b2 100644\n--- a/Documentation/gitfaq.txt\n+++ b/Documentation/gitfaq.txt\n@@ -401,8 +401,9 @@ I'm on Windows and git diff shows my files as having a `^M` at the end.::\n +\n You can store the files in the repository with Unix line endings and convert\n them automatically to your platform's line endings. To do that, set the\n-configuration option `core.eol` to `native` and see the following entry for\n-information about how to configure files as text or binary.\n+configuration option `core.eol` to `native` and see\n+<>\n+for information about how to configure files as text or binary.\n +\n You can also control this behavior with the `core.whitespace` setting if you\n don't wish to remove the carriage returns from your line endings.\n@@ -464,14 +465,25 @@ references, URLs, and hashes stored in the repository.\n +\n We also recommend setting a linkgit:gitattributes[5] file to explicitly mark\n which files are text and which are binary. If you want Git to guess, you can\n-set the attribute `text=auto`. For example, the following might be appropriate\n-in some projects:\n+set the attribute `text=auto`.\n++\n+With text files, Git will generally the repository contains LF endings in the\n+repository, and will honor `core.autocrlf` and `core.eol` to decide what options\n+to use when checking files out. You can also override this by specifying a\n+particular line ending such as `eol=lf` or `eol=crlf` if those files must always\n+have that ending (e.g., for functionality reasons).\n++\n+For example, the following might be appropriate in some projects:\n +\n ----\n # By default, guess.\n *\ttext=auto\n # Mark all C files as text.\n *.c\ttext\n+# Ensure all shell files end up with LF endings and all batch files end up\n+# with CRLF endings in the working tree and both end up with LF in the repo.\n+*.sh text eol=lf\n+*.bat text eol=crlf\n # Mark all JPEG files as binary.\n *.jpg\tbinary\n ----\n"},{"id":"439075","messageId":"20211020010624.675562-5-sandals@crustytoothpaste.net","threadId":"56743","inReplyTo":"20211020010624.675562-1-sandals@crustytoothpaste.net","subject":"[PATCH 4/4] doc: add a FAQ entry about syncing working trees","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T01:06:23Z","receivedAt":"2021-10-20T01:06:37Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Users very commonly want to sync their working tree across machines,\noften to carry across in-progress work or stashes. Despite this not\nbeing a recommended approach, users want to do it and are not dissuaded\nby suggestions not to, so let's recommend a sensible technique.\n\nThe technique that many users are using is their preferred cloud syncing\nservice, which is a bad idea. Users have reported problems where they\nend up with duplicate files that won't go away (with names like \"file.c\n2\"), broken references, oddly named references that have date stamps\nappended to them, missing objects, and general corruption and data loss.\nThat's because almost all of these tools sync file by file, which is a\ngreat technique if your project is a single word processing document or\nspreadsheet, but is utterly abysmal for Git repositories because they\ndon't necessarily snapshot the entire repository correctly. They also\ntend to sync the files immediately instead of when the repository is\nquiescent, so writing multiple files, as occurs during a commit or a gc,\ncan confuse the tools and lead to corruption.\n\nWe know that the old standby, rsync, is up to the task, provided that\nthe repository is quiescent, so let's suggest that and dissuade people\nfrom using cloud syncing tools. Let's tell people about common things\nthey should be aware of before doing this and that this is still\npotentially risky. Additionally, let's tell people that Git's security\nmodel does not permit sharing working trees across users in case they\nplanned to do that. While we'd still prefer users didn't try to do\nthis, hopefully this will lead them in a safer direction.\n\nSigned-off-by: brian m. carlson \n---\n Documentation/gitfaq.txt | 43 ++++++++++++++++++++++++++++++++++++++--\n 1 file changed, 41 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\nindex 85ac99c7b2..4a8a46f980 100644\n--- a/Documentation/gitfaq.txt\n+++ b/Documentation/gitfaq.txt\n@@ -83,8 +83,8 @@ Windows would be the configuration `\"C:\\Program Files\\Vim\\gvim.exe\" --nofork`,\n which quotes the filename with spaces and specifies the `--nofork` option to\n avoid backgrounding the process.\n \n-Credentials\n------------\n+Credentials and Transfers\n+-------------------------\n \n [[http-credentials]]\n How do I specify my credentials when pushing over HTTP?::\n@@ -185,6 +185,45 @@ Then, you can adjust your push URL to use `git@example_author` or\n `git@example_committer` instead of `git@example.org` (e.g., `git remote set-url\n git@example_author:org1/project1.git`).\n \n+[[sync-working-tree]]\n+How do I sync a working tree across systems?::\n+\tFirst, decide whether you want to do this at all. Git usually works better\n+\twhen you push or pull your work using the typical `git push` and `git fetch`\n+\tcommands and isn't designed to share a working tree across systems. Doing so\n+\tcan cause `git status` to need to re-read every file in the working tree.\n+\tAdditionally, Git's security model does not permit sharing a working tree\n+\tacross untrusted users, so it is only safe to sync a working tree if it will\n+\tonly be used by a single user across all machines.\n++\n+Therefore, it's better to push your work to either the other system or a central\n+server using the normal push and pull mechanism. However, this doesn't always\n+preserve important data, like stashes, so some people prefer to share a working\n+tree across systems.\n++\n+It is important not to use a cloud syncing service to sync any portion of a Git\n+repository, since this can cause corruption, such as missing objects, changed\n+or added files, broken refs, and a wide variety of other corruption. These\n+services tend to sync file by file and don't understand the structure of a Git\n+repository. This is especially bad if they sync the repository in the middle of\n+it being updated, since that is very likely to cause incomplete or partial\n+updates and therefore data loss.\n++\n+The recommended approach is to use `rsync -a --delete-after` (ideally with an\n+encrypted connection such as with `ssh`) on the root of repository. You should\n+ensure several things when you do this:\n++\n+* There are no additional worktrees enabled for your repository.\n+* You are not using a separate Git directory outside of your repository root.\n+* You are comfortable with the destination directory being an exact copy of the\n+\tsource directory, _deleting any data that is already there_.\n+* The repository is in a quiescent state for the duration of the transfer (that\n+\tis, no operations of any sort are taking place on it, including background\n+\toperations like `git gc`).\n++\n+Be aware that even with these recommendations, syncing in this way is\n+potentially risky since it bypasses Git's normal integrity checking for\n+repositories, so having backups is advised.\n+\n Common Issues\n -------------\n \n"},{"id":"439076","messageId":"20211020010624.675562-6-sandals@crustytoothpaste.net","threadId":"56743","inReplyTo":"20211020010624.675562-1-sandals@crustytoothpaste.net","subject":"[PATCH 4/4] gitfaq: add entry about syncing working trees","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T01:06:24Z","receivedAt":"2021-10-20T01:06:38Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Users very commonly want to sync their working tree across machines,\noften to carry across in-progress work or stashes. Despite this not\nbeing a recommended approach, users want to do it and are not dissuaded\nby suggestions not to, so let's recommend a sensible technique.\n\nThe technique that many users are using is their preferred cloud syncing\nservice, which is a bad idea. Users have reported problems where they\nend up with duplicate files that won't go away (with names like \"file.c\n2\"), broken references, oddly named references that have date stamps\nappended to them, missing objects, and general corruption and data loss.\nThat's because almost all of these tools sync file by file, which is a\ngreat technique if your project is a single word processing document or\nspreadsheet, but is utterly abysmal for Git repositories because they\ndon't necessarily snapshot the entire repository correctly. They also\ntend to sync the files immediately instead of when the repository is\nquiescent, so writing multiple files, as occurs during a commit or a gc,\ncan confuse the tools and lead to corruption.\n\nWe know that the old standby, rsync, is up to the task, provided that\nthe repository is quiescent, so let's suggest that and dissuade people\nfrom using cloud syncing tools. Let's tell people about common things\nthey should be aware of before doing this and that this is still\npotentially risky. Additionally, let's tell people that Git's security\nmodel does not permit sharing working trees across users in case they\nplanned to do that. While we'd still prefer users didn't try to do\nthis, hopefully this will lead them in a safer direction.\n\nSigned-off-by: brian m. carlson \n---\n Documentation/gitfaq.txt | 43 ++++++++++++++++++++++++++++++++++++++--\n 1 file changed, 41 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\nindex 85ac99c7b2..4a8a46f980 100644\n--- a/Documentation/gitfaq.txt\n+++ b/Documentation/gitfaq.txt\n@@ -83,8 +83,8 @@ Windows would be the configuration `\"C:\\Program Files\\Vim\\gvim.exe\" --nofork`,\n which quotes the filename with spaces and specifies the `--nofork` option to\n avoid backgrounding the process.\n \n-Credentials\n------------\n+Credentials and Transfers\n+-------------------------\n \n [[http-credentials]]\n How do I specify my credentials when pushing over HTTP?::\n@@ -185,6 +185,45 @@ Then, you can adjust your push URL to use `git@example_author` or\n `git@example_committer` instead of `git@example.org` (e.g., `git remote set-url\n git@example_author:org1/project1.git`).\n \n+[[sync-working-tree]]\n+How do I sync a working tree across systems?::\n+\tFirst, decide whether you want to do this at all. Git usually works better\n+\twhen you push or pull your work using the typical `git push` and `git fetch`\n+\tcommands and isn't designed to share a working tree across systems. Doing so\n+\tcan cause `git status` to need to re-read every file in the working tree.\n+\tAdditionally, Git's security model does not permit sharing a working tree\n+\tacross untrusted users, so it is only safe to sync a working tree if it will\n+\tonly be used by a single user across all machines.\n++\n+Therefore, it's better to push your work to either the other system or a central\n+server using the normal push and pull mechanism. However, this doesn't always\n+preserve important data, like stashes, so some people prefer to share a working\n+tree across systems.\n++\n+It is important not to use a cloud syncing service to sync any portion of a Git\n+repository, since this can cause corruption, such as missing objects, changed\n+or added files, broken refs, and a wide variety of other corruption. These\n+services tend to sync file by file and don't understand the structure of a Git\n+repository. This is especially bad if they sync the repository in the middle of\n+it being updated, since that is very likely to cause incomplete or partial\n+updates and therefore data loss.\n++\n+The recommended approach is to use `rsync -a --delete-after` (ideally with an\n+encrypted connection such as with `ssh`) on the root of repository. You should\n+ensure several things when you do this:\n++\n+* There are no additional worktrees enabled for your repository.\n+* You are not using a separate Git directory outside of your repository root.\n+* You are comfortable with the destination directory being an exact copy of the\n+\tsource directory, _deleting any data that is already there_.\n+* The repository is in a quiescent state for the duration of the transfer (that\n+\tis, no operations of any sort are taking place on it, including background\n+\toperations like `git gc`).\n++\n+Be aware that even with these recommendations, syncing in this way is\n+potentially risky since it bypasses Git's normal integrity checking for\n+repositories, so having backups is advised.\n+\n Common Issues\n -------------\n \n"},{"id":"439077","messageId":"20211020010624.675562-2-sandals@crustytoothpaste.net","threadId":"56743","inReplyTo":"20211020010624.675562-1-sandals@crustytoothpaste.net","subject":"[PATCH 1/4] gitfaq: add advice on monorepos","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T01:06:20Z","receivedAt":"2021-10-20T01:07:04Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Many projects around the world have chosen monorepos, and active\ndevelopment on Git is ongoing to support them better. However, as\nprojects using monorepos grow, they often find various performance\nand scalability problems that are unpleasant to deal with.\n\nAdd a FAQ entry to note that while Git is attempting improvements in\nthis area, it is not uncommon to see performance problems that\nnecessitate the use of partial or shallow clone, sparse checkout, or the\nlike, and that if users wish to avoid these problems, avoiding a\nmonorepo may be best.\n\nSigned-off-by: brian m. carlson \n---\n Documentation/gitfaq.txt | 26 ++++++++++++++++++++++++++\n 1 file changed, 26 insertions(+)\n\ndiff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\nindex 8c1f2d5675..946691c153 100644\n--- a/Documentation/gitfaq.txt\n+++ b/Documentation/gitfaq.txt\n@@ -241,6 +241,32 @@ How do I know if I want to do a fetch or a pull?::\n \tignore the upstream changes. A pull consists of a fetch followed\n \timmediately by either a merge or rebase. See linkgit:git-pull[1].\n \n+Design\n+------\n+\n+[[monorepos]]\n+Should we use a monorepo or many individual repos?::\n+\tThis is a decision that is typically made based on an organization's needs and\n+\tdesires for their projects. Git has several features, such as shallow clone,\n+\tpartial clone, and sparse checkout to make working with large repositories\n+\teasier, and there is active development on making the monorepo experience\n+\tbetter.\n++\n+However, at a certain size, the performance of a monorepo will likely become\n+unacceptable _unless_ you use these features. If you choose to start with a\n+monorepo and continue to grow, you may end up unhappy with the performance\n+characteristics at a point where making a change is difficult. The performance\n+of using many smaller repositories will almost always be much better and will\n+generally not necessitate the use of these more advanced features. If you are\n+concerned about future performance of your repository and related tools, you may\n+wish to avoid a monorepo.\n++\n+Ultimately, you should make a decision fully informed about the potential\n+benefits and downsides, including the capabilities, performance, and future\n+requirements for your repository and related tools, including your hosting\n+platform, build tools, and other programs you typically use as part of your\n+workflow.\n+\n Merging and Rebasing\n --------------------\n \n"},{"id":"439078","messageId":"20211020010624.675562-3-sandals@crustytoothpaste.net","threadId":"56743","inReplyTo":"20211020010624.675562-1-sandals@crustytoothpaste.net","subject":"[PATCH 2/4] gitfaq: add documentation on proxies","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T01:06:21Z","receivedAt":"2021-10-20T01:07:04Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Many corporate environments and local systems have proxies in use. Note\nthe situations in which proxies can be used and how to configure them.\nAt the same time, note what standards a proxy must follow to work with\nGit. Explicitly call out certain classes that are known to routinely\nhave problems reported various places online, including in the Git for\nWindows issue tracker and on Stack Overflow, and recommend against the\nuse of such software.\n\nSigned-off-by: brian m. carlson \n---\n Documentation/gitfaq.txt | 18 ++++++++++++++++++\n 1 file changed, 18 insertions(+)\n\ndiff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\nindex 946691c153..abc0f62e6c 100644\n--- a/Documentation/gitfaq.txt\n+++ b/Documentation/gitfaq.txt\n@@ -241,6 +241,24 @@ How do I know if I want to do a fetch or a pull?::\n \tignore the upstream changes. A pull consists of a fetch followed\n \timmediately by either a merge or rebase. See linkgit:git-pull[1].\n \n+[[proxy]]\n+Can I use a proxy with Git?::\n+\tYes, Git supports the use of proxies. Git honors the standard `http_proxy`,\n+\t`https_proxy`, and `no_proxy` environment variables commonly used on Unix, and\n+\tit also can be configured with `http.proxy` and similar options for HTTPS (see\n+\tlinkgit:git-config[1]). The `http.proxy` and related options can be\n+\tcustomized on a per-URL pattern basis. In addition, Git can in theory\n+\tfunction normally with transparent proxies that exist on the network.\n++\n+However, note that for Git to work properly, the proxy must be completely\n+transparent. The proxy cannot modify, tamper with, change, or buffer the\n+connection in any way, or Git will almost certainly fail to work. Note that\n+many proxies, including many TLS middleboxes, Windows antivirus and firewall\n+programs other than Windows Defender and Windows Firewall, and filtering proxies\n+fail to meet this standard, and as a result end up breaking Git. Because of the\n+many reports of problems, we recommend against the use of these classes of\n+software and devices.\n+\n Design\n ------\n \n"},{"id":"439079","messageId":"CAPig+cTn4fZtssPrn+z582E++Kdc2+z+=iNtp2kodR=QJVeycg@mail.gmail.com","threadId":"56743","inReplyTo":"20211020010624.675562-4-sandals@crustytoothpaste.net","subject":"Re: [PATCH 3/4] gitfaq: give advice on using eol attribute in gitattributes","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-10-20T01:21:40Z","receivedAt":"2021-10-20T01:21:55Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Oct 19, 2021 at 9:06 PM brian m. carlson\n wrote:\n> In the FAQ, we tell people how to use the text attribute, but we fail to\n> explain what to do with the eol attribute. As we ourselves have\n> noticed, most shell implementations do not care for carriage returns,\n> and as such, people will practically always want them to use LF endings.\n> Similar things can be said for batch files on Windows, except with CRLF\n> endings.\n>\n> Since these are common things to have in a repository, let's help users\n> make a good decision by recommending that they use the gitattributes\n> file to correctly check out the endings.\n>\n> In addition, let's correct the cross-reference to this question, which\n> originally referred to \"the following entry\", even though a new entry\n> has been inserted in between. The cross-reference notation should\n> prevent this from occurring and provide a link in formats, such as HTML,\n> which support that.\n>\n> Signed-off-by: brian m. carlson \n> ---\n> diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\n> @@ -464,14 +465,25 @@ references, URLs, and hashes stored in the repository.\n> +With text files, Git will generally the repository contains LF endings in the\n> +repository, and will honor `core.autocrlf` and `core.eol` to decide what options\n> +to use when checking files out. You can also override this by specifying a\n> +particular line ending such as `eol=lf` or `eol=crlf` if those files must always\n> +have that ending (e.g., for functionality reasons).\n\nThe first sentence in the paragraph is unparseable.\n\n> +# Ensure all shell files end up with LF endings and all batch files end up\n> +# with CRLF endings in the working tree and both end up with LF in the repo.\n> +*.sh text eol=lf\n> +*.bat text eol=crlf\n\nMaybe: s/end up with/have/g\n"},{"id":"439080","messageId":"YW9wgbN/b8NkVp4z@camp.crustytoothpaste.net","threadId":"56743","inReplyTo":"CAPig+cTn4fZtssPrn+z582E++Kdc2+z+=iNtp2kodR=QJVeycg@mail.gmail.com","subject":"Re: [PATCH 3/4] gitfaq: give advice on using eol attribute in gitattributes","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T01:27:29Z","receivedAt":"2021-10-20T01:27:36Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-10-20 at 01:21:40, Eric Sunshine wrote:\n> On Tue, Oct 19, 2021 at 9:06 PM brian m. carlson\n> wrote:\n> > In the FAQ, we tell people how to use the text attribute, but we fail to\n> > explain what to do with the eol attribute. As we ourselves have\n> > noticed, most shell implementations do not care for carriage returns,\n> > and as such, people will practically always want them to use LF endings.\n> > Similar things can be said for batch files on Windows, except with CRLF\n> > endings.\n> >\n> > Since these are common things to have in a repository, let's help users\n> > make a good decision by recommending that they use the gitattributes\n> > file to correctly check out the endings.\n> >\n> > In addition, let's correct the cross-reference to this question, which\n> > originally referred to \"the following entry\", even though a new entry\n> > has been inserted in between. The cross-reference notation should\n> > prevent this from occurring and provide a link in formats, such as HTML,\n> > which support that.\n> >\n> > Signed-off-by: brian m. carlson \n> > ---\n> > diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\n> > @@ -464,14 +465,25 @@ references, URLs, and hashes stored in the repository.\n> > +With text files, Git will generally the repository contains LF endings in the\n> > +repository, and will honor `core.autocrlf` and `core.eol` to decide what options\n> > +to use when checking files out. You can also override this by specifying a\n> > +particular line ending such as `eol=lf` or `eol=crlf` if those files must always\n> > +have that ending (e.g., for functionality reasons).\n> \n> The first sentence in the paragraph is unparseable.\n\nYes, I think perhaps I omitted the word \"ensure\".\n\nAnd I should reflect that they should have that ending in the working\ntree, which I neglected to mention.\n\n> > +# Ensure all shell files end up with LF endings and all batch files end up\n> > +# with CRLF endings in the working tree and both end up with LF in the repo.\n> > +*.sh text eol=lf\n> > +*.bat text eol=crlf\n> \n> Maybe: s/end up with/have/g\n\nGreat. That does read more clearly and succinctly.\n\nI'll include those fixes in a reroll.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"439081","messageId":"CAPig+cR=wQYthORMfyf4ShBCTXyWkQJqH6YHuW4Uv-Ys3wef5g@mail.gmail.com","threadId":"56743","inReplyTo":"20211020010624.675562-6-sandals@crustytoothpaste.net","subject":"Re: [PATCH 4/4] gitfaq: add entry about syncing working trees","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-10-20T01:38:47Z","receivedAt":"2021-10-20T01:39:00Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Oct 19, 2021 at 9:06 PM brian m. carlson\n wrote:\n> gitfaq: add entry about syncing working trees\n\nYou sent two [4/4] patches. I'm guessing the one prefixed by \"gitfaq:\"\nis the correct one.\n\n> Users very commonly want to sync their working tree across machines,\n> often to carry across in-progress work or stashes. Despite this not\n> being a recommended approach, users want to do it and are not dissuaded\n> by suggestions not to, so let's recommend a sensible technique.\n> [...]\n> Signed-off-by: brian m. carlson \n> ---\n> diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\n> @@ -185,6 +185,45 @@ Then, you can adjust your push URL to use `git@example_author` or\n> +[[sync-working-tree]]\n> +How do I sync a working tree across systems?::\n> + First, decide whether you want to do this at all. Git usually works better\n> + when you push or pull your work using the typical `git push` and `git fetch`\n> + commands and isn't designed to share a working tree across systems. Doing so\n> + can cause `git status` to need to re-read every file in the working tree.\n> + Additionally, Git's security model does not permit sharing a working tree\n> + across untrusted users, so it is only safe to sync a working tree if it will\n> + only be used by a single user across all machines.\n> ++\n> +Therefore, it's better to push your work to either the other system or a central\n> +server using the normal push and pull mechanism. However, this doesn't always\n> +preserve important data, like stashes, so some people prefer to share a working\n> +tree across systems.\n> ++\n> +It is important not to use a cloud syncing service to sync any portion of a Git\n> +repository, since this can cause corruption, such as missing objects, changed\n> +or added files, broken refs, and a wide variety of other corruption. These\n> +services tend to sync file by file and don't understand the structure of a Git\n> +repository. This is especially bad if they sync the repository in the middle of\n> +it being updated, since that is very likely to cause incomplete or partial\n> +updates and therefore data loss.\n> ++\n> +The recommended approach is to use `rsync -a --delete-after` (ideally with an\n> +encrypted connection such as with `ssh`) on the root of repository. You should\n> +ensure several things when you do this:\n> [...]\n> +Be aware that even with these recommendations, syncing in this way is\n> +potentially risky since it bypasses Git's normal integrity checking for\n> +repositories, so having backups is advised.\n\nConsidering the potential damage which can result from this sort of\nsynching, this entire section seems too gentle. My knee-jerk reaction\nis that it would be better to strongly dissuade upfront rather than\nsaying that it's okay to do this if you really want to. As such, I'm\nwondering if organizing the section like this would be better:\n\n(1) Make a strong statement against doing this: \"Don't do it.\"\n\n(2) Explain why users shouldn't do it; in particular, the final\nparagraph above which talks about integrity checks and whatnot should\nbe right up near the top along with discussion of corruption.\n\n(3) Say that cloud-synching services must _not_ be used and explain why.\n\n(4) Relent a tiny bit and explain that the only slightly acceptable\nmechanism is `rsync` when used in a very strict fashion (quiescent\nrepository, etc.)\n"},{"id":"439083","messageId":"9652166a-9db3-9e14-5fad-ef0deede9f28@gmail.com","threadId":"56743","inReplyTo":"20211020010624.675562-2-sandals@crustytoothpaste.net","subject":"Re: [PATCH 1/4] gitfaq: add advice on monorepos","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-10-20T04:45:22Z","receivedAt":"2021-10-20T04:45:30Z","isPatch":true,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 20/10/21 08.06, brian m. carlson wrote:\n> +[[monorepos]]\n> +Should we use a monorepo or many individual repos?::\n> +\tThis is a decision that is typically made based on an organization's needs and\n> +\tdesires for their projects. Git has several features, such as shallow clone,\n> +\tpartial clone, and sparse checkout to make working with large repositories\n> +\teasier, and there is active development on making the monorepo experience\n> +\tbetter.\n> ++\n> +However, at a certain size, the performance of a monorepo will likely become\n> +unacceptable _unless_ you use these features. If you choose to start with a\n> +monorepo and continue to grow, you may end up unhappy with the performance\n> +characteristics at a point where making a change is difficult. The performance\n> +of using many smaller repositories will almost always be much better and will\n> +generally not necessitate the use of these more advanced features. If you are\n> +concerned about future performance of your repository and related tools, you may\n> +wish to avoid a monorepo.\n> ++\n> +Ultimately, you should make a decision fully informed about the potential\n> +benefits and downsides, including the capabilities, performance, and future\n> +requirements for your repository and related tools, including your hosting\n> +platform, build tools, and other programs you typically use as part of your\n> +workflow.\n> +\n> Merging and Rebasing\n> --------------------\n> \n> \n\nIt seems like recommending to split repo, right?\n\nUltimately, if people choose split repo instead of monorepo, it will \nonly delay the necessity to use advanced features (partial/shallow \nclones, sparse checkout, etc.) when the repos become large.\n\nFor balanced view, we should describe benefits and drawbacks of both \nmonorepo and split repos.\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"439084","messageId":"a2719de4-d8ec-5e78-bb73-7712c07c90c7@gmail.com","threadId":"56743","inReplyTo":"20211020010624.675562-5-sandals@crustytoothpaste.net","subject":"Re: [PATCH 4/4] doc: add a FAQ entry about syncing working trees","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-10-20T04:58:48Z","receivedAt":"2021-10-20T04:58:54Z","isPatch":true,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 20/10/21 08.06, brian m. carlson wrote:\n> +Be aware that even with these recommendations, syncing in this way is\n> +potentially risky since it bypasses Git's normal integrity checking for\n> +repositories, so having backups is advised.\n> +\n\nThis raises question: how users can backup their repos? The answer is \nsame as this FAQ for syncing working trees: have your repo to be pushed \nto the spare server at disposal, or use rsync (as long as the \npreconditions are met).\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"439085","messageId":"211020.86h7dcndlm.gmgdl@evledraar.gmail.com","threadId":"56743","inReplyTo":"20211020010624.675562-2-sandals@crustytoothpaste.net","subject":"Re: [PATCH 1/4] gitfaq: add advice on monorepos","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-10-20T10:54:47Z","receivedAt":"2021-10-20T11:24:25Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Oct 20 2021, brian m. carlson wrote:\n\n> +[[monorepos]]\n> +Should we use a monorepo or many individual repos?::\n> +\tThis is a decision that is typically made based on an organization's needs and\n> +\tdesires for their projects. Git has several features, such as shallow clone,\n> +\tpartial clone, and sparse checkout to make working with large repositories\n> +\teasier, and there is active development on making the monorepo experience\n> +\tbetter.\n> ++\n> +However, at a certain size, the performance of a monorepo will likely become\n> +unacceptable _unless_ you use these features. If you choose to start with a\n> +monorepo and continue to grow, you may end up unhappy with the performance\n> +characteristics at a point where making a change is difficult. The performance\n> +of using many smaller repositories will almost always be much better and will\n> +generally not necessitate the use of these more advanced features. If you are\n> +concerned about future performance of your repository and related tools, you may\n> +wish to avoid a monorepo.\n> ++\n> +Ultimately, you should make a decision fully informed about the potential\n> +benefits and downsides, including the capabilities, performance, and future\n> +requirements for your repository and related tools, including your hosting\n> +platform, build tools, and other programs you typically use as part of your\n> +workflow.\n\nIn the context of git development we're typically talking about really\nbig repos when we're talking about monorepos, saying \"monorepo\"\ncommunicates among other things that the user of that pattern is\nunwilling to use splitting up as a way to address any scalability issues\nthey may have.\n\nBut a monorepo doesn't really say anything about size per-se, and it\nwould be confusing to conflate the two in a FAQ. I may be wrong, perhaps\nthe term has really come to exclusively refer to colossal size, but I\nhaven't seen or heard it exclusively (or even mainly) used like that\n\nMy understanding of what a monorepo in the context of software\ndevelopment is a collection of all your \"main\" code and all its\ndependencies in one repository, such that a person working on it rarely\nor never has to worry about N=N dependencies between different pieces of\nthat collection, they'll all move in unison. You are able to atomically\nchange a function and all its users.\n\nI think people have a different understanding of \"all its\ndependencies\". Some monorepo users really mean it and try to e.g. fold\ntheir system configuration system that might manage files in /etc in\nwith their monorepo, others might have \"another monorepo\" for that\nsoftware, etc.\n\nI bet that the vast majority of monorepo users are never going to\nexperience scaling problems, e.g. having your laptop dotfiles and\nautomation of /etc in one repo is a \"monorepo\", and most companies/teams\nthat use monorepos I'd bet are in the long tail of size\ndistribution. They're not going to grow to the size of a MS's, FB's\netc. monorepo, but they might benefit (or not) from the monorepo\n/workflow/.\n\nAnyway, all of the above can be read as a suggestion that we should\nsplit any discussion of \"large repo [that runs into scaling issues]\"\nfrom \"monorepo\", the latter should of course make a passing reference to\nscaling (as the pattern will lead to that sooner than not), but IMO not\nconflate the two.\n"},{"id":"439088","messageId":"nycvar.QRO.7.76.6.2110201349570.56@tvgsbejvaqbjf.bet","threadId":"56743","inReplyTo":"20211020010624.675562-2-sandals@crustytoothpaste.net","subject":"Re: [PATCH 1/4] gitfaq: add advice on monorepos","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-10-20T11:55:43Z","receivedAt":"2021-10-20T11:56:02Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi brian,\n\nthank you for this excellent idea to talk about monorepos.\n\nOn Wed, 20 Oct 2021, brian m. carlson wrote:\n\n> diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\n> index 8c1f2d5675..946691c153 100644\n> --- a/Documentation/gitfaq.txt\n> +++ b/Documentation/gitfaq.txt\n> @@ -241,6 +241,32 @@ How do I know if I want to do a fetch or a pull?::\n> \tignore the upstream changes. A pull consists of a fetch followed\n> \timmediately by either a merge or rebase. See linkgit:git-pull[1].\n>\n> +Design\n> +------\n> +\n> +[[monorepos]]\n> +Should we use a monorepo or many individual repos?::\n> +\tThis is a decision that is typically made based on an organization's needs and\n> +\tdesires for their projects. Git has several features, such as shallow clone,\n> +\tpartial clone, and sparse checkout to make working with large repositories\n\nMay I request taking out shallow clones? A user new to Git might think\nthat shallow clones are a sane way to clone a large repository. In\npractice, this only makes sense for \"throw-away\" clones, though. As soon\nas you fetch in such clones, performance will be so horrible that it is\nfrequently a better idea to start with a partial clone instead.\n\nAt the same time, I would like to swap in \"sparse index\" for \"shallow\nclone\" because it _does_ have the best potential of all currently\ndiscussed new features to improve performance with monorepos.\n\n> +\teasier, and there is active development on making the monorepo experience\n> +\tbetter.\n> ++\n> +However, at a certain size, the performance of a monorepo will likely become\n> +unacceptable _unless_ you use these features. If you choose to start with a\n\nI would like to add a plug for Scalar here. Maybe we can link to this\n\"opinionated tool based on Git\" here? I wouldn't ask if I didn't _know_\nthat it helps monorepo users out there.\n\n> +monorepo and continue to grow, you may end up unhappy with the performance\n> +characteristics at a point where making a change is difficult. The performance\n> +of using many smaller repositories will almost always be much better and will\n> +generally not necessitate the use of these more advanced features. If you are\n> +concerned about future performance of your repository and related tools, you may\n> +wish to avoid a monorepo.\n> ++\n> +Ultimately, you should make a decision fully informed about the potential\n> +benefits and downsides, including the capabilities, performance, and future\n> +requirements for your repository and related tools, including your hosting\n> +platform, build tools, and other programs you typically use as part of your\n> +workflow.\n\nI wish we had a good article to link to, here. Yes, it is a decision that\nshould be fully informed, and yes, this FAQ entry is not the place for a\nthorough discussion of monorepos and how Git can be asked to handle them\nmore efficiently.\n\nDo you know of any good resource that we could use here?\n\nThanks,\nDscho\n\n> +\n> Merging and Rebasing\n> --------------------\n>\n>\n"},{"id":"439089","messageId":"nycvar.QRO.7.76.6.2110201357110.56@tvgsbejvaqbjf.bet","threadId":"56743","inReplyTo":"20211020010624.675562-3-sandals@crustytoothpaste.net","subject":"Re: [PATCH 2/4] gitfaq: add documentation on proxies","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-10-20T11:57:42Z","receivedAt":"2021-10-20T11:58:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi brian,\n\nOn Wed, 20 Oct 2021, brian m. carlson wrote:\n\n> Many corporate environments and local systems have proxies in use. Note\n> the situations in which proxies can be used and how to configure them.\n> At the same time, note what standards a proxy must follow to work with\n> Git. Explicitly call out certain classes that are known to routinely\n> have problems reported various places online, including in the Git for\n> Windows issue tracker and on Stack Overflow, and recommend against the\n> use of such software.\n\nI fully agree with this patch, therefore: ACK!\n\nCiao,\nDscho\n"},{"id":"439091","messageId":"nycvar.QRO.7.76.6.2110201400020.56@tvgsbejvaqbjf.bet","threadId":"56743","inReplyTo":"YW9wgbN/b8NkVp4z@camp.crustytoothpaste.net","subject":"Re: [PATCH 3/4] gitfaq: give advice on using eol attribute in gitattributes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-10-20T12:02:02Z","receivedAt":"2021-10-20T12:02:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi brian,\n\nOn Wed, 20 Oct 2021, brian m. carlson wrote:\n\n> On 2021-10-20 at 01:21:40, Eric Sunshine wrote:\n> > On Tue, Oct 19, 2021 at 9:06 PM brian m. carlson\n> > wrote:\n> >\n> > > diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\n> > > @@ -464,14 +465,25 @@ references, URLs, and hashes stored in the repository.\n> > > +With text files, Git will generally the repository contains LF endings in the\n> > > +repository, and will honor `core.autocrlf` and `core.eol` to decide what options\n> > > +to use when checking files out. You can also override this by specifying a\n> > > +particular line ending such as `eol=lf` or `eol=crlf` if those files must always\n> > > +have that ending (e.g., for functionality reasons).\n> >\n> > The first sentence in the paragraph is unparseable.\n>\n> Yes, I think perhaps I omitted the word \"ensure\".\n>\n> And I should reflect that they should have that ending in the working\n> tree, which I neglected to mention.\n\nPlease note that Git for Windows defaults to `core.autoCRLF=true`,\ntherefore this sentence is not completely correct. Maybe something as\nshort as \"(except in Git for Windows, which defaults to CRLF endings)\"\nwould suffice?\n\nCiao,\nDscho\n"},{"id":"439092","messageId":"nycvar.QRO.7.76.6.2110201403420.56@tvgsbejvaqbjf.bet","threadId":"56743","inReplyTo":"20211020010624.675562-6-sandals@crustytoothpaste.net","subject":"Re: [PATCH 4/4] gitfaq: add entry about syncing working trees","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-10-20T12:09:02Z","receivedAt":"2021-10-20T12:09:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi brian,\n\nOn Wed, 20 Oct 2021, brian m. carlson wrote:\n\n> Users very commonly want to sync their working tree across machines,\n\nI was confused at first, because I do sync my working trees frequently. I\ndo this via `git push` and `git pull`, though.\n\nMaybe clarify that you mean rsync, or sync services like DropBox and\nOneDrive? I see that you mention \"cloud syncing service\" below, but I\nbelieve that it might be better to lead with the examples.\n\n> often to carry across in-progress work or stashes. Despite this not\n> being a recommended approach, users want to do it and are not dissuaded\n> by suggestions not to, so let's recommend a sensible technique.\n>\n> The technique that many users are using is their preferred cloud syncing\n> service, which is a bad idea. Users have reported problems where they\n> end up with duplicate files that won't go away (with names like \"file.c\n> 2\"), broken references, oddly named references that have date stamps\n> appended to them, missing objects, and general corruption and data loss.\n> That's because almost all of these tools sync file by file, which is a\n> great technique if your project is a single word processing document or\n> spreadsheet, but is utterly abysmal for Git repositories because they\n> don't necessarily snapshot the entire repository correctly. They also\n> tend to sync the files immediately instead of when the repository is\n> quiescent, so writing multiple files, as occurs during a commit or a gc,\n> can confuse the tools and lead to corruption.\n>\n> We know that the old standby, rsync, is up to the task, provided that\n> the repository is quiescent, so let's suggest that and dissuade people\n> from using cloud syncing tools. Let's tell people about common things\n> they should be aware of before doing this and that this is still\n> potentially risky. Additionally, let's tell people that Git's security\n> model does not permit sharing working trees across users in case they\n> planned to do that. While we'd still prefer users didn't try to do\n> this, hopefully this will lead them in a safer direction.\n\nThe remainder of the commit message is very clear.\n\nThank you,\nDscho\n"},{"id":"439105","messageId":"3f92dde3-fdcc-fb76-7ebc-2c3cf8191af2@iee.email","threadId":"56743","inReplyTo":"a2719de4-d8ec-5e78-bb73-7712c07c90c7@gmail.com","subject":"Re: [PATCH 4/4] doc: add a FAQ entry about syncing working trees","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-10-20T14:05:46Z","receivedAt":"2021-10-20T14:05:50Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 20/10/2021 05:58, Bagas Sanjaya wrote:\n> On 20/10/21 08.06, brian m. carlson wrote:\n>> +Be aware that even with these recommendations, syncing in this way is\n>> +potentially risky since it bypasses Git's normal integrity checking for\n>> +repositories, so having backups is advised.\n>> +\n>\n> This raises question: how users can backup their repos? The answer is\n> same as this FAQ for syncing working trees: have your repo to be\n> pushed to the spare server at disposal, or use rsync (as long as the\n> preconditions are met).\n>\nPerhaps, for backing up a repo, users might be pointed toward `git\nbundle` (with caveats about `--all` being over complete..)\n\n-- \nPhilip\n"},{"id":"439106","messageId":"557fe5b8-36b4-a760-d2dd-02137746a37b@iee.email","threadId":"56743","inReplyTo":"20211020010624.675562-2-sandals@crustytoothpaste.net","subject":"Re: [PATCH 1/4] gitfaq: add advice on monorepos","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-10-20T14:11:09Z","receivedAt":"2021-10-20T14:11:13Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 20/10/2021 02:06, brian m. carlson wrote:\n> Many projects around the world have chosen monorepos, and active\n> development on Git is ongoing to support them better. However, as\n> projects using monorepos grow, they often find various performance\n> and scalability problems that are unpleasant to deal with.\n>\n> Add a FAQ entry to note that while Git is attempting improvements in\n> this area, it is not uncommon to see performance problems that\n> necessitate the use of partial or shallow clone, sparse checkout, or the\n> like, and that if users wish to avoid these problems, avoiding a\n> monorepo may be best.\n>\n> Signed-off-by: brian m. carlson \n> ---\n> Documentation/gitfaq.txt | 26 ++++++++++++++++++++++++++\n> 1 file changed, 26 insertions(+)\n>\n> diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\n> index 8c1f2d5675..946691c153 100644\n> --- a/Documentation/gitfaq.txt\n> +++ b/Documentation/gitfaq.txt\n> @@ -241,6 +241,32 @@ How do I know if I want to do a fetch or a pull?::\n> \tignore the upstream changes. A pull consists of a fetch followed\n> \timmediately by either a merge or rebase. See linkgit:git-pull[1].\n> \n> +Design\n> +------\n> +\n> +[[monorepos]]\n> +Should we use a monorepo or many individual repos?::\n> +\tThis is a decision that is typically made based on an organization's needs and\n> +\tdesires for their projects. Git has several features, such as shallow clone,\n> +\tpartial clone, and sparse checkout to make working with large repositories\n> +\teasier, and there is active development on making the monorepo experience\n> +\tbetter.\n> ++\n> +However, at a certain size, the performance of a monorepo will likely become\n> +unacceptable _unless_ you use these features. If you choose to start with a\n> +monorepo and continue to grow, you may end up unhappy with the performance\n> +characteristics at a point where making a change is difficult. The performance\n> +of using many smaller repositories will almost always be much better and will\n> +generally not necessitate the use of these more advanced features. If you are\n> +concerned about future performance of your repository and related tools, you may\n> +wish to avoid a monorepo.\n> ++\n> +Ultimately, you should make a decision fully informed about the potential\n> +benefits and downsides, including the capabilities, performance, and future\n> +requirements for your repository and related tools, including your hosting\n> +platform, build tools, and other programs you typically use as part of your\n> +workflow.\n> +\n\nDoes this need some comparison, or link, with sub-module methods and\nissues? Such as the nested sub-module problem, the distinction between\nactive sub-modules and quiescent sub-modules (e.g. libraries Vx.y.z)?\n\nAs an aside, I don't think we provide any background to the Git\nphilosophy that frames some of these issues.\n\n-- \nPhilip\n\n"},{"id":"439114","messageId":"xmqqbl3jrbvf.fsf@gitster.g","threadId":"56743","inReplyTo":"20211020010624.675562-3-sandals@crustytoothpaste.net","subject":"Re: [PATCH 2/4] gitfaq: add documentation on proxies","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-20T14:48:04Z","receivedAt":"2021-10-20T14:48:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> Many corporate environments and local systems have proxies in use. Note\n> the situations in which proxies can be used and how to configure them.\n> At the same time, note what standards a proxy must follow to work with\n> Git. Explicitly call out certain classes that are known to routinely\n> have problems reported various places online, including in the Git for\n> Windows issue tracker and on Stack Overflow, and recommend against the\n> use of such software.\n\nThe new section only talks about http(s), but I recall Peff recently\nhelped folks with broken invocation of socat, a relay that does not\nhandle severing connection only in one direction very well.\n\nI wonder if it fits in this section.\n\n> Signed-off-by: brian m. carlson \n> ---\n> Documentation/gitfaq.txt | 18 ++++++++++++++++++\n> 1 file changed, 18 insertions(+)\n>\n> diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\n> index 946691c153..abc0f62e6c 100644\n> --- a/Documentation/gitfaq.txt\n> +++ b/Documentation/gitfaq.txt\n> @@ -241,6 +241,24 @@ How do I know if I want to do a fetch or a pull?::\n> \tignore the upstream changes. A pull consists of a fetch followed\n> \timmediately by either a merge or rebase. See linkgit:git-pull[1].\n> \n> +[[proxy]]\n> +Can I use a proxy with Git?::\n> +\tYes, Git supports the use of proxies. Git honors the standard `http_proxy`,\n> +\t`https_proxy`, and `no_proxy` environment variables commonly used on Unix, and\n> +\tit also can be configured with `http.proxy` and similar options for HTTPS (see\n> +\tlinkgit:git-config[1]). The `http.proxy` and related options can be\n> +\tcustomized on a per-URL pattern basis. In addition, Git can in theory\n> +\tfunction normally with transparent proxies that exist on the network.\n> ++\n> +However, note that for Git to work properly, the proxy must be completely\n> +transparent. The proxy cannot modify, tamper with, change, or buffer the\n> +connection in any way, or Git will almost certainly fail to work. Note that\n> +many proxies, including many TLS middleboxes, Windows antivirus and firewall\n> +programs other than Windows Defender and Windows Firewall, and filtering proxies\n> +fail to meet this standard, and as a result end up breaking Git. Because of the\n> +many reports of problems, we recommend against the use of these classes of\n> +software and devices.\n> +\n> Design\n> ------\n> \n"},{"id":"439141","messageId":"YXCHxdYot+fCHwl1@camp.crustytoothpaste.net","threadId":"56743","inReplyTo":"211020.86h7dcndlm.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH 1/4] gitfaq: add advice on monorepos","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T21:19:01Z","receivedAt":"2021-10-20T21:19:54Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-10-20 at 10:54:47, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Wed, Oct 20 2021, brian m. carlson wrote:\n> \n> > +[[monorepos]]\n> > +Should we use a monorepo or many individual repos?::\n> > +\tThis is a decision that is typically made based on an organization's needs and\n> > +\tdesires for their projects. Git has several features, such as shallow clone,\n> > +\tpartial clone, and sparse checkout to make working with large repositories\n> > +\teasier, and there is active development on making the monorepo experience\n> > +\tbetter.\n> > ++\n> > +However, at a certain size, the performance of a monorepo will likely become\n> > +unacceptable _unless_ you use these features. If you choose to start with a\n> > +monorepo and continue to grow, you may end up unhappy with the performance\n> > +characteristics at a point where making a change is difficult. The performance\n> > +of using many smaller repositories will almost always be much better and will\n> > +generally not necessitate the use of these more advanced features. If you are\n> > +concerned about future performance of your repository and related tools, you may\n> > +wish to avoid a monorepo.\n> > ++\n> > +Ultimately, you should make a decision fully informed about the potential\n> > +benefits and downsides, including the capabilities, performance, and future\n> > +requirements for your repository and related tools, including your hosting\n> > +platform, build tools, and other programs you typically use as part of your\n> > +workflow.\n> \n> In the context of git development we're typically talking about really\n> big repos when we're talking about monorepos, saying \"monorepo\"\n> communicates among other things that the user of that pattern is\n> unwilling to use splitting up as a way to address any scalability issues\n> they may have.\n> \n> But a monorepo doesn't really say anything about size per-se, and it\n> would be confusing to conflate the two in a FAQ. I may be wrong, perhaps\n> the term has really come to exclusively refer to colossal size, but I\n> haven't seen or heard it exclusively (or even mainly) used like that\n\nI routinely hear \"monorepo\" used to imply repositories of specifically\nlarge size. However, I'm happy to rephrase to make it clearer.\n\n> I bet that the vast majority of monorepo users are never going to\n> experience scaling problems, e.g. having your laptop dotfiles and\n> automation of /etc in one repo is a \"monorepo\", and most companies/teams\n> that use monorepos I'd bet are in the long tail of size\n> distribution. They're not going to grow to the size of a MS's, FB's\n> etc. monorepo, but they might benefit (or not) from the monorepo\n> /workflow/.\n\nI almost never hear individuals refer to such a configuration as a\nmonorepo. Technically, it is one, yes, but I almost always hear it in\nthe context of an organization's repository covering all of their\nservices or the entirety of one major project.\n\nI will point out that I personally would run into scaling issues if I\nput all of my projects in the same repository. I have many projects,\nand that would quickly become unsustainable, since the resources I have\nat my disposal are more limited than most organizations.\n\n> Anyway, all of the above can be read as a suggestion that we should\n> split any discussion of \"large repo [that runs into scaling issues]\"\n> from \"monorepo\", the latter should of course make a passing reference to\n> scaling (as the pattern will lead to that sooner than not), but IMO not\n> conflate the two.\n\nI'm happy to clarify, but I think we need to mention the word \"monorepo\"\nspecifically because (a) that's the term that's commonly used for this\napproach and (b) that approach is one that tends to lead to\nsignificantly greater growth in a single repository leading to scale\nproblems.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"439144","messageId":"YXCL6dyhoBA708X0@camp.crustytoothpaste.net","threadId":"56743","inReplyTo":"CAPig+cR=wQYthORMfyf4ShBCTXyWkQJqH6YHuW4Uv-Ys3wef5g@mail.gmail.com","subject":"Re: [PATCH 4/4] gitfaq: add entry about syncing working trees","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T21:36:41Z","receivedAt":"2021-10-20T21:37:35Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-10-20 at 01:38:47, Eric Sunshine wrote:\n> On Tue, Oct 19, 2021 at 9:06 PM brian m. carlson\n> wrote:\n> > gitfaq: add entry about syncing working trees\n> \n> You sent two [4/4] patches. I'm guessing the one prefixed by \"gitfaq:\"\n> is the correct one.\n\nYes, I appear to have done a bad cherry-pick. Will fix in v2.\n\n> Considering the potential damage which can result from this sort of\n> synching, this entire section seems too gentle. My knee-jerk reaction\n> is that it would be better to strongly dissuade upfront rather than\n> saying that it's okay to do this if you really want to. As such, I'm\n> wondering if organizing the section like this would be better:\n> \n> (1) Make a strong statement against doing this: \"Don't do it.\"\n\nI agree this is dangerous. The reason this is so painful is why I long\nago stopped having a desktop: I needed to sync in-progress work\nfrequently, and having multiple machines is too much of a hassle for\nthat case. The laptop is more portable and can be used everywhere, even\nif less powerful.\n\nHowever, some people do legitimately need to work on the same project\nacross machines, and the current tooling for syncing stashes and other\nin-progress work is insufficient. Therefore, if we just tell people,\n\"Don't do this,\" they're going to stop reading and ignore us, because\nwe've neglected their needs and they have a job to do. That would be\nworse, because instead of using something like rsync, they might use a\ncloud syncing service, and then they'll be really in a bad place.\n\nHowever, I'm happy to try the reorganization you proposed, even if I\ndon't necessarily adopt the strength of the proposal, and see how it works.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"439147","messageId":"YXCVXvQYxVhj2aWN@camp.crustytoothpaste.net","threadId":"56743","inReplyTo":"nycvar.QRO.7.76.6.2110201357110.56@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 2/4] gitfaq: add documentation on proxies","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T22:17:02Z","receivedAt":"2021-10-20T22:17:54Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-10-20 at 11:57:42, Johannes Schindelin wrote:\n> Hi brian,\n> \n> On Wed, 20 Oct 2021, brian m. carlson wrote:\n> \n> > Many corporate environments and local systems have proxies in use. Note\n> > the situations in which proxies can be used and how to configure them.\n> > At the same time, note what standards a proxy must follow to work with\n> > Git. Explicitly call out certain classes that are known to routinely\n> > have problems reported various places online, including in the Git for\n> > Windows issue tracker and on Stack Overflow, and recommend against the\n> > use of such software.\n> \n> I fully agree with this patch, therefore: ACK!\n\nI CC'd you specifically because of this patch, and I'm glad to hear you\nagree, even if I'm sorry you have to deal with these reports.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"439148","messageId":"YXCV3GYpwe8uCfQo@camp.crustytoothpaste.net","threadId":"56743","inReplyTo":"xmqqbl3jrbvf.fsf@gitster.g","subject":"Re: [PATCH 2/4] gitfaq: add documentation on proxies","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T22:19:08Z","receivedAt":"2021-10-20T22:19:30Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-10-20 at 14:48:04, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n> > Many corporate environments and local systems have proxies in use. Note\n> > the situations in which proxies can be used and how to configure them.\n> > At the same time, note what standards a proxy must follow to work with\n> > Git. Explicitly call out certain classes that are known to routinely\n> > have problems reported various places online, including in the Git for\n> > Windows issue tracker and on Stack Overflow, and recommend against the\n> > use of such software.\n> \n> The new section only talks about http(s), but I recall Peff recently\n> helped folks with broken invocation of socat, a relay that does not\n> handle severing connection only in one direction very well.\n> \n> I wonder if it fits in this section.\n\nI think it does, and I'll add it in a reroll.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"439149","messageId":"YXCWigr6TovYXgbb@camp.crustytoothpaste.net","threadId":"56743","inReplyTo":"557fe5b8-36b4-a760-d2dd-02137746a37b@iee.email","subject":"Re: [PATCH 1/4] gitfaq: add advice on monorepos","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T22:22:02Z","receivedAt":"2021-10-20T22:22:23Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-10-20 at 14:11:09, Philip Oakley wrote:\n> Does this need some comparison, or link, with sub-module methods and\n> issues? Such as the nested sub-module problem, the distinction between\n> active sub-modules and quiescent sub-modules (e.g. libraries Vx.y.z)?\n\nI don't think it does. Some projects choose to use many repositories\nwith submodules, and some use many repositories without submodules. At\nwork, we do the latter, and it tends to work just fine.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"439150","messageId":"YXCXU8uns1Xld5lH@camp.crustytoothpaste.net","threadId":"56743","inReplyTo":"nycvar.QRO.7.76.6.2110201400020.56@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 3/4] gitfaq: give advice on using eol attribute in gitattributes","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-20T22:25:23Z","receivedAt":"2021-10-20T22:25:45Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-10-20 at 12:02:02, Johannes Schindelin wrote:\n> Hi brian,\n> \n> On Wed, 20 Oct 2021, brian m. carlson wrote:\n> \n> > On 2021-10-20 at 01:21:40, Eric Sunshine wrote:\n> > > On Tue, Oct 19, 2021 at 9:06 PM brian m. carlson\n> > > wrote:\n> > >\n> > > > diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\n> > > > @@ -464,14 +465,25 @@ references, URLs, and hashes stored in the repository.\n> > > > +With text files, Git will generally the repository contains LF endings in the\n> > > > +repository, and will honor `core.autocrlf` and `core.eol` to decide what options\n> > > > +to use when checking files out. You can also override this by specifying a\n> > > > +particular line ending such as `eol=lf` or `eol=crlf` if those files must always\n> > > > +have that ending (e.g., for functionality reasons).\n> > >\n> > > The first sentence in the paragraph is unparseable.\n> >\n> > Yes, I think perhaps I omitted the word \"ensure\".\n> >\n> > And I should reflect that they should have that ending in the working\n> > tree, which I neglected to mention.\n> \n> Please note that Git for Windows defaults to `core.autoCRLF=true`,\n> therefore this sentence is not completely correct. Maybe something as\n> short as \"(except in Git for Windows, which defaults to CRLF endings)\"\n> would suffice?\n\nWhat I meant by that sentence was that I should add, \"in the working\ntree\" to the sentence ending \"if those files must always have that\nending\". I believe that is still the case for Git for Windows, since\notherwise our shell files in the repository would be broken there, and\nI'm fairly confident they are not.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"439152","messageId":"211021.86r1cfmfhh.gmgdl@evledraar.gmail.com","threadId":"56743","inReplyTo":"20211020010624.675562-5-sandals@crustytoothpaste.net","subject":"Re: [PATCH 4/4] doc: add a FAQ entry about syncing working trees","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-10-20T23:35:43Z","receivedAt":"2021-10-20T23:41:19Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Oct 20 2021, brian m. carlson wrote:\n\n> +The recommended approach is to use `rsync -a --delete-after` (ideally with an\n> +encrypted connection such as with `ssh`) on the root of repository. You should\n> +ensure several things when you do this:\n\nWhat's the reason to recommend --delete-after in particular? I realize\nthat e.g. in the .git directory not using *A* delete option *will* cause\ncorruption, e.g. if you can leave behind stale loose refs with an\nup-to-date pack-refs file.\n\nBut isn't that equally covered by --delete and --delete-before? I'm not\nvery well worsed in rsync, but aren't the two equivalent as far as the\nend-state goes?\n\nIf the intention with --delete-after over --delete or --delete-before is\nto somehow make the repository useful during the transfer, doesn't that\ngo against the later advice of:\n\n> +* The repository is in a quiescent state for the duration of the transfer (that\n> +\tis, no operations of any sort are taking place on it, including background\n> +\toperations like `git gc`).\n\nAlso for this:\n\n> +Be aware that even with these recommendations, syncing in this way is\n> +potentially risky since it bypasses Git's normal integrity checking for\n> +repositories, so having backups is advised.\n\nPerhaps we should recommend running a \"git gc\" or other integrity check\nafter (or \"git fsck\"), although those don't cover some cases, e.g. the\npack-refs v.s. loose refs problem in the case of a missing\n--delete-whatever.\n"},{"id":"439154","messageId":"YXCuQ3KID6iq0vwa@camp.crustytoothpaste.net","threadId":"56743","inReplyTo":"211021.86r1cfmfhh.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH 4/4] doc: add a FAQ entry about syncing working trees","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-21T00:03:15Z","receivedAt":"2021-10-21T00:04:09Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-10-20 at 23:35:43, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Wed, Oct 20 2021, brian m. carlson wrote:\n> \n> > +The recommended approach is to use `rsync -a --delete-after` (ideally with an\n> > +encrypted connection such as with `ssh`) on the root of repository. You should\n> > +ensure several things when you do this:\n> \n> What's the reason to recommend --delete-after in particular? I realize\n> that e.g. in the .git directory not using *A* delete option *will* cause\n> corruption, e.g. if you can leave behind stale loose refs with an\n> up-to-date pack-refs file.\n> \n> But isn't that equally covered by --delete and --delete-before? I'm not\n> very well worsed in rsync, but aren't the two equivalent as far as the\n> end-state goes?\n\nYes. The goal is that if something goes wrong, you have all the objects\nyou did before, even if you have some potentially invalid refs. The\ngoal is to make it a little less risky if you interrupt it with a Ctrl-C\nbecause you realize the destination contained data you wanted. I always\nprefer --delete-after for that reason, assuming the destination has\nsufficient disk space.\n\nIt shouldn't make a difference in a successful end state, however.\n> \n> > +Be aware that even with these recommendations, syncing in this way is\n> > +potentially risky since it bypasses Git's normal integrity checking for\n> > +repositories, so having backups is advised.\n> \n> Perhaps we should recommend running a \"git gc\" or other integrity check\n> after (or \"git fsck\"), although those don't cover some cases, e.g. the\n> pack-refs v.s. loose refs problem in the case of a missing\n> --delete-whatever.\n\nI can recommend something like that.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"439156","messageId":"211021.86mtn3mcph.gmgdl@evledraar.gmail.com","threadId":"56743","inReplyTo":"YXCuQ3KID6iq0vwa@camp.crustytoothpaste.net","subject":"Re: [PATCH 4/4] doc: add a FAQ entry about syncing working trees","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-10-21T00:33:49Z","receivedAt":"2021-10-21T00:41:19Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Oct 21 2021, brian m. carlson wrote:\n\n> [[PGP Signed Part:Undecided]]\n> On 2021-10-20 at 23:35:43, Ævar Arnfjörð Bjarmason wrote:\n>> \n>> On Wed, Oct 20 2021, brian m. carlson wrote:\n>> \n>> > +The recommended approach is to use `rsync -a --delete-after` (ideally with an\n>> > +encrypted connection such as with `ssh`) on the root of repository. You should\n>> > +ensure several things when you do this:\n>> \n>> What's the reason to recommend --delete-after in particular? I realize\n>> that e.g. in the .git directory not using *A* delete option *will* cause\n>> corruption, e.g. if you can leave behind stale loose refs with an\n>> up-to-date pack-refs file.\n>> \n>> But isn't that equally covered by --delete and --delete-before? I'm not\n>> very well worsed in rsync, but aren't the two equivalent as far as the\n>> end-state goes?\n>\n> Yes. The goal is that if something goes wrong, you have all the objects\n> you did before, even if you have some potentially invalid refs. The\n> goal is to make it a little less risky if you interrupt it with a Ctrl-C\n> because you realize the destination contained data you wanted. I always\n> prefer --delete-after for that reason, assuming the destination has\n> sufficient disk space.\n\nIsn't it preferable to recommend --delete-before for that reason?\nI.e. --delete-after will produce subtle corruption of e.g. refs\npotentially pointing to the wrong thing.\n\nBut if you recommend --delete-before I think (but maybe I'm missing some\ncases) that it will be more likely to produce obvious corruption,\ne.g. git dying due to missing objects.\n\nAnyway, I'm also happy to just leave this as-is, it just stood out to me\nas od..\n\n> It shouldn't make a difference in a successful end state, however.\n>> \n>> > +Be aware that even with these recommendations, syncing in this way is\n>> > +potentially risky since it bypasses Git's normal integrity checking for\n>> > +repositories, so having backups is advised.\n>> \n>> Perhaps we should recommend running a \"git gc\" or other integrity check\n>> after (or \"git fsck\"), although those don't cover some cases, e.g. the\n>> pack-refs v.s. loose refs problem in the case of a missing\n>> --delete-whatever.\n>\n> I can recommend something like that.\n\n...or just leave it as-is is also fine with me, whatever you think is\nbest.\n"},{"id":"439197","messageId":"nycvar.QRO.7.76.6.2110211359410.56@tvgsbejvaqbjf.bet","threadId":"56743","inReplyTo":"YXCXU8uns1Xld5lH@camp.crustytoothpaste.net","subject":"Re: [PATCH 3/4] gitfaq: give advice on using eol attribute in gitattributes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-10-21T12:02:36Z","receivedAt":"2021-10-21T12:03:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi brian,\n\nOn Wed, 20 Oct 2021, brian m. carlson wrote:\n\n> On 2021-10-20 at 12:02:02, Johannes Schindelin wrote:\n> > Hi brian,\n> >\n> > On Wed, 20 Oct 2021, brian m. carlson wrote:\n> >\n> > > On 2021-10-20 at 01:21:40, Eric Sunshine wrote:\n> > > > On Tue, Oct 19, 2021 at 9:06 PM brian m. carlson\n> > > > wrote:\n> > > >\n> > > > > diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\n> > > > > @@ -464,14 +465,25 @@ references, URLs, and hashes stored in the repository.\n> > > > > +With text files, Git will generally the repository contains LF endings in the\n> > > > > +repository, and will honor `core.autocrlf` and `core.eol` to decide what options\n> > > > > +to use when checking files out. You can also override this by specifying a\n> > > > > +particular line ending such as `eol=lf` or `eol=crlf` if those files must always\n> > > > > +have that ending (e.g., for functionality reasons).\n> > > >\n> > > > The first sentence in the paragraph is unparseable.\n> > >\n> > > Yes, I think perhaps I omitted the word \"ensure\".\n> > >\n> > > And I should reflect that they should have that ending in the working\n> > > tree, which I neglected to mention.\n> >\n> > Please note that Git for Windows defaults to `core.autoCRLF=true`,\n> > therefore this sentence is not completely correct. Maybe something as\n> > short as \"(except in Git for Windows, which defaults to CRLF endings)\"\n> > would suffice?\n>\n> What I meant by that sentence was that I should add, \"in the working\n> tree\" to the sentence ending \"if those files must always have that\n> ending\". I believe that is still the case for Git for Windows, since\n> otherwise our shell files in the repository would be broken there, and\n> I'm fairly confident they are not.\n\nI swear I read this sentence multiple times yesterday, and still managed\nto miss that you were talking about LF endings _in the repository_.\n\nFWIW I think that `core.autoCRLF` defaults to `off` everywhere but on\nWindows, so _technically_ Git would not ensure LF endings e.g. on Linux.\nIn practice, it is highly unlikely that a Linux user would generate text\nfiles with CR/LF endings, so it would not matter in practice.\n\nI feel a bit bad for arguing subtleties that realistically won't matter,\nso please feel free to leave the sentence as you have intended it.\n\nCiao,\nDscho\n"},{"id":"439526","messageId":"48d2b707-3337-8232-af19-dc6170e12313@iee.email","threadId":"56743","inReplyTo":"YXCWigr6TovYXgbb@camp.crustytoothpaste.net","subject":"Re: [PATCH 1/4] gitfaq: add advice on monorepos","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-10-25T10:44:07Z","receivedAt":"2021-10-25T10:44:11Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Brian,\nOn 20/10/2021 23:22, brian m. carlson wrote:\n> On 2021-10-20 at 14:11:09, Philip Oakley wrote:\n>> Does this need some comparison, or link, with sub-module methods and\n>> issues? Such as the nested sub-module problem, the distinction between\n>> active sub-modules and quiescent sub-modules (e.g. libraries Vx.y.z)?\n> I don't think it does. Some projects choose to use many repositories\n> with submodules, and some use many repositories without submodules. At\n> work, we do the latter, and it tends to work just fine.\n\nTo clarify, my comment was with regard to the complementary discussions\nabout _choice_ of repo types, rather than mono-repo and other\npost-choice issues. Possibly, part of such a discussion on choice of\nrepo-type, could include the potential slippery slope between the\ndifferent uses of sub-modules.\n\nI feel a lot of the difficult sub-module discussion are because we don't\nhave a common terminology for the different (mental) models of\nsub-module use, their benefits and problems.\n--\nPhilip\n"}]}