{"thread":{"id":"53172","subject":"[PATCH 0/2] Add more issues in gitfaq","startedAt":"2020-04-06T18:12:34Z","lastAt":"2020-04-10T18:29:15Z","messageCount":10,"participants":["Shourya Shukla","Junio C Hamano","brian m. carlson","Pratyush Yadav"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"394873","messageId":"20200406181216.5340-1-shouryashukla.oo@gmail.com","threadId":"53172","inReplyTo":null,"subject":"[PATCH 0/2] Add more issues in gitfaq","fromName":"Shourya Shukla","fromEmail":"shouryashukla.oo@gmail.com","sentAt":"2020-04-06T18:12:14Z","receivedAt":"2020-04-06T18:12:34Z","isPatch":true,"sender":{"key":"shouryashukla.oo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43680618?v=4"},"body":"I have tried adding more issues and their respective solutions in the\ngitfaq. Please feel free to point out any mistakes I have made in any\nsense here. I have tried to add some basic questions such as difference\nbetween rebasing and merging, changing remote, etc.\n\nI intend to add even more changes in the further patches. Also, one\nthing I wanted to ask is whether I should add a sort of guide section to\nconfiguring 'send-email' and a using 'format-patch'. Although there does\nexist a man page for the same but I thought that a simpler and all at\none place version could be made.\n\nOne suggestion I have is that we should have an INDEX/CONTENTS section\nin this guide because the end user may not know whether solution to a\nparticular problem exists here or not.\n\nRegards,\nShourya Shukla\n\nShourya Shukla (2):\n  gitfaq: cleanup gitfaq.txt\n  gitfaq: append the 'Common Issues' section\n\n Documentation/gitfaq.txt | 182 +++++++++++++++++++++++++++------------\n 1 file changed, 127 insertions(+), 55 deletions(-)\n\n-- \n2.20.1\n\n"},{"id":"394874","messageId":"20200406181216.5340-2-shouryashukla.oo@gmail.com","threadId":"53172","inReplyTo":"20200406181216.5340-1-shouryashukla.oo@gmail.com","subject":"[PATCH 1/2] gitfaq: cleanup gitfaq.txt","fromName":"Shourya Shukla","fromEmail":"shouryashukla.oo@gmail.com","sentAt":"2020-04-06T18:12:15Z","receivedAt":"2020-04-06T18:12:37Z","isPatch":true,"sender":{"key":"shouryashukla.oo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43680618?v=4"},"body":"The file contained a lot of whitespace errors as well as some\ngrammatical mistakes. Amend them.\n\nSigned-off-by: Shourya Shukla <shouryashukla.oo@gmail.com>\n---\n Documentation/gitfaq.txt | 110 +++++++++++++++++++--------------------\n 1 file changed, 55 insertions(+), 55 deletions(-)\n\ndiff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\nindex 1cf83df118..3ca16b1092 100644\n--- a/Documentation/gitfaq.txt\n+++ b/Documentation/gitfaq.txt\n@@ -23,7 +23,7 @@ Configuration\n What should I put in `user.name`?::\n \tYou should put your personal name, generally a form using a given name\n \tand family name.  For example, the current maintainer of Git uses \"Junio\n-\tC Hamano\".  This will be the name portion that is stored in every commit\n+\tC Hamano\". This will be the name portion that is stored in every commit\n \tyou make.\n +\n This configuration doesn't have any effect on authenticating to remote services;\n@@ -32,7 +32,7 @@ for that, see `credential.username` in linkgit:git-config[1].\n [[http-postbuffer]]\n What does `http.postBuffer` really do?::\n \tThis option changes the size of the buffer that Git uses when pushing\n-\tdata to a remote over HTTP or HTTPS.  If the data is larger than this\n+\tdata to a remote over HTTP or HTTPS. If the data is larger than this\n \tsize, libcurl, which handles the HTTP support for Git, will use chunked\n \ttransfer encoding since it isn't known ahead of time what the size of\n \tthe pushed data will be.\n@@ -40,15 +40,15 @@ What does `http.postBuffer` really do?::\n Leaving this value at the default size is fine unless you know that either the\n remote server or a proxy in the middle doesn't support HTTP/1.1 (which\n introduced the chunked transfer encoding) or is known to be broken with chunked\n-data.  This is often (erroneously) suggested as a solution for generic push\n+data. This is often (erroneously) suggested as a solution for generic push\n problems, but since almost every server and proxy supports at least HTTP/1.1,\n-raising this value usually doesn't solve most push problems.  A server or proxy\n+raising this value usually doesn't solve most push problems. A server or proxy\n that didn't correctly support HTTP/1.1 and chunked transfer encoding wouldn't be\n that useful on the Internet today, since it would break lots of traffic.\n +\n Note that increasing this value will increase the memory used on every relevant\n push that Git does over HTTP or HTTPS, since the entire buffer is allocated\n-regardless of whether or not it is all used.  Thus, it's best to leave it at the\n+regardless of whether or not it is all used. Thus, it's best to leave it at the\n default unless you are sure you need a different value.\n \n [[configure-editor]]\n@@ -56,13 +56,13 @@ How do I configure a different editor?::\n \tIf you haven't specified an editor specifically for Git, it will by default\n \tuse the editor you've configured using the `VISUAL` or `EDITOR` environment\n \tvariables, or if neither is specified, the system default (which is usually\n-\t`vi`).  Since some people find `vi` difficult to use or prefer a different\n+\t`vi`). Since some people find `vi` difficult to use or prefer a different\n \teditor, it may be desirable to change the editor used.\n +\n If you want to configure a general editor for most programs which need one, you\n can edit your shell configuration (e.g., `~/.bashrc` or `~/.zshenv`) to contain\n a line setting the `EDITOR` or `VISUAL` environment variable to an appropriate\n-value.  For example, if you prefer the editor `nano`, then you could write the\n+value. For example, if you prefer the editor `nano`, then you could write the\n following:\n +\n ----\n@@ -70,15 +70,15 @@ export VISUAL=nano\n ----\n +\n If you want to configure an editor specifically for Git, you can either set the\n-`core.editor` configuration value or the `GIT_EDITOR` environment variable.  You\n+`core.editor` configuration value or the `GIT_EDITOR` environment variable. You\n can see linkgit:git-var[1] for details on the order in which these options are\n consulted.\n +\n Note that in all cases, the editor value will be passed to the shell, so any\n-arguments containing spaces should be appropriately quoted.  Additionally, if\n+arguments containing spaces should be appropriately quoted. Additionally, if\n your editor normally detaches from the terminal when invoked, you should specify\n it with an argument that makes it not do that, or else Git will not see any\n-changes.  An example of a configuration addressing both of these issues on\n+changes. An example of a configuration addressing both of these issues on\n 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@@ -89,11 +89,11 @@ Credentials\n [[http-credentials]]\n How do I specify my credentials when pushing over HTTP?::\n \tThe easiest way to do this is to use a credential helper via the\n-\t`credential.helper` configuration.  Most systems provide a standard\n-\tchoice to integrate with the system credential manager.  For example,\n+\t`credential.helper` configuration. Most systems provide a standard\n+\tchoice to integrate with the system credential manager. For example,\n \tGit for Windows provides the `wincred` credential manager, macOS has the\n \t`osxkeychain` credential manager, and Unix systems with a standard\n-\tdesktop environment can use the `libsecret` credential manager.  All of\n+\tdesktop environment can use the `libsecret` credential manager. All of\n \tthese store credentials in an encrypted store to keep your passwords or\n \ttokens secure.\n +\n@@ -102,7 +102,7 @@ in your home directory, or the `cache` credential manager, which does not\n permanently store your credentials, but does prevent you from being prompted for\n them for a certain period of time.\n +\n-You can also just enter your password when prompted.  While it is possible to\n+You can also just enter your password when prompted. While it is possible to\n place the password (which must be percent-encoded) in the URL, this is not\n particularly secure and can lead to accidental exposure of credentials, so it is\n not recommended.\n@@ -113,8 +113,8 @@ How do I read a password or token from an environment variable?::\n \tshell command that produces the credential protocol on standard output.\n \tThis is useful when passing credentials into a container, for example.\n +\n-Such a shell command can be specified by starting the option value with an\n-exclamation point.  If your password or token were stored in the `GIT_TOKEN`,\n+Such a shell command can be specified by putting an exclamation point before\n+the option. If your password or token were stored in the `GIT_TOKEN`,\n you could run the following command to set your credential helper:\n +\n ----\n@@ -125,10 +125,10 @@ $ git config credential.helper \\\n [[http-reset-credentials]]\n How do I change the password or token I've saved in my credential manager?::\n \tUsually, if the password or token is invalid, Git will erase it and\n-\tprompt for a new one.  However, there are times when this doesn't always\n-\thappen.  To change the password or token, you can erase the existing\n-\tcredentials and then Git will prompt for new ones.  To erase\n-\tcredentials, use a syntax like the following (substituting your username\n+\tprompt for a new one. However, there are times when this doesn't always\n+\thappen. To change the password or token, you can erase the existing\n+\tcredentials and then Git will prompt for new ones. To erase credentials,\n+\tuse a syntax like the following (substituting your username\n \tand the hostname):\n +\n ----\n@@ -138,12 +138,12 @@ $ echo url=https://author@git.example.org | git credential reject\n [[multiple-accounts-http]]\n How do I use multiple accounts with the same hosting provider using HTTP?::\n \tUsually the easiest way to distinguish between these accounts is to use\n-\tthe username in the URL.  For example, if you have the accounts `author`\n+\tthe username in the URL. For example, if you have the accounts `author`\n \tand `committer` on `git.example.org`, you can use the URLs\n \thttps://author@git.example.org/org1/project1.git and\n-\thttps://committer@git.example.org/org2/project2.git.  This way, when you\n+\thttps://committer@git.example.org/org2/project2.git. This way, when you\n \tuse a credential helper, it will automatically try to look up the\n-\tcorrect credentials for your account.  If you already have a remote set\n+\tcorrect credentials for your account. If you already have a remote set\n \tup, you can change the URL with something like `git remote set-url\n \torigin https://author@git.example.org/org1/project1.git` (see\n \tlinkgit:git-remote[1] for details).\n@@ -151,17 +151,17 @@ How do I use multiple accounts with the same hosting provider using HTTP?::\n [[multiple-accounts-ssh]]\n How do I use multiple accounts with the same hosting provider using SSH?::\n \tWith most hosting providers that support SSH, a single key pair uniquely\n-\tidentifies a user.  Therefore, to use multiple accounts, it's necessary\n-\tto create a key pair for each account.  If you're using a reasonably\n+\tidentifies a user. Therefore, to use multiple accounts, it's necessary\n+\tto create a key pair for each account. If you're using a reasonably\n \tmodern OpenSSH version, you can create a new key pair with something\n-\tlike `ssh-keygen -t ed25519 -f ~/.ssh/id_committer`.  You can then\n+\tlike `ssh-keygen -t ed25519 -f ~/.ssh/id_committer`. You can then\n \tregister the public key (in this case, `~/.ssh/id_committer.pub`; note\n \tthe `.pub`) with the hosting provider.\n +\n Most hosting providers use a single SSH account for pushing; that is, all users\n-push to the `git` account (e.g., `git@git.example.org`).  If that's the case for\n+push to the `git` account (e.g., `git@git.example.org`). If that's the case for\n your provider, you can set up multiple aliases in SSH to make it clear which key\n-pair to use.  For example, you could write something like the following in\n+pair to use. For example, you could write something like the following in\n `~/.ssh/config`, substituting the proper private key file:\n +\n ----\n@@ -189,29 +189,29 @@ Common Issues\n -------------\n \n [[last-commit-amend]]\n-I've made a mistake in the last commit.  How do I change it?::\n+I've made a mistake in the last commit. How do I change it?::\n \tYou can make the appropriate change to your working tree, run `git add\n \t<file>` or `git rm <file>`, as appropriate, to stage it, and then `git\n-\tcommit --amend`.  Your change will be included in the commit, and you'll\n+\tcommit --amend`. Your change will be included in the commit, and you'll\n \tbe prompted to edit the commit message again; if you wish to use the\n \toriginal message verbatim, you can use the `--no-edit` option to `git\n \tcommit` in addition, or just save and quit when your editor opens.\n \n [[undo-previous-change]]\n-I've made a change with a bug and it's been included in the main branch.  How should I undo it?::\n-\tThe usual way to deal with this is to use `git revert`.  This preserves\n+I've made a change with a bug and it's been included in the main branch. How should I undo it?::\n+\tThe usual way to deal with this is to use `git revert`. This preserves\n \tthe history that the original change was made and was a valuable\n \tcontribution, but also introduces a new commit that undoes those changes\n-\tbecause the original had a problem.  The commit message of the revert\n+\tbecause the original had a problem. The commit message of the revert\n \tindicates the commit which was reverted and is usually edited to include\n \tan explanation as to why the revert was made.\n \n [[ignore-tracked-files]]\n-How do I ignore changes to a tracked file?::\n-\tGit doesn't provide a way to do this.  The reason is that if Git needs\n+How do I ignore changes made to a tracked file?::\n+\tGit doesn't provide a way to do this. The reason is that if Git needs\n \tto overwrite this file, such as during a checkout, it doesn't know\n \twhether the changes to the file are precious and should be kept, or\n-\twhether they are irrelevant and can safely be destroyed.  Therefore, it\n+\twhether they are irrelevant and can safely be destroyed. Therefore, it\n \thas to take the safe route and always preserve them.\n +\n It's tempting to try to use certain features of `git update-index`, namely the\n@@ -220,7 +220,7 @@ purpose and shouldn't be used this way.\n +\n If your goal is to modify a configuration file, it can often be helpful to have\n a file checked into the repository which is a template or set of defaults which\n-can then be copied alongside and modified as appropriate.  This second, modified\n+can then be copied alongside and modified as appropriate. This second, modified\n file is usually ignored to prevent accidentally committing it.\n \n Hooks\n@@ -230,12 +230,12 @@ Hooks\n How do I use hooks to prevent users from making certain changes?::\n \tThe only safe place to make these changes is on the remote repository\n \t(i.e., the Git server), usually in the `pre-receive` hook or in a\n-\tcontinuous integration (CI) system.  These are the locations in which\n+\tcontinuous integration (CI) system. These are the locations in which\n \tpolicy can be enforced effectively.\n +\n It's common to try to use `pre-commit` hooks (or, for commit messages,\n `commit-msg` hooks) to check these things, which is great if you're working as a\n-solo developer and want the tooling to help you.  However, using hooks on a\n+solo developer and want the tooling to help you. However, using hooks on a\n developer machine is not effective as a policy control because a user can bypass\n these hooks with `--no-verify` without being noticed (among various other ways).\n Git assumes that the user is in control of their local repositories and doesn't\n@@ -251,24 +251,24 @@ Cross-Platform Issues\n \n [[windows-text-binary]]\n I'm on Windows and my text files are detected as binary.::\n-\tGit works best when you store text files as UTF-8.  Many programs on\n+\tGit works best when you store text files as UTF-8. Many programs on\n \tWindows support UTF-8, but some do not and only use the little-endian\n-\tUTF-16 format, which Git detects as binary.  If you can't use UTF-8 with\n+\tUTF-16 format, which Git detects as binary. If you can't use UTF-8 with\n \tyour programs, you can specify a working tree encoding that indicates\n \twhich encoding your files should be checked out with, while still\n-\tstoring these files as UTF-8 in the repository.  This allows tools like\n+\tstoring these files as UTF-8 in the repository. This allows tools like\n \tlinkgit:git-diff[1] to work as expected, while still allowing your tools\n \tto work.\n +\n To do so, you can specify a linkgit:gitattributes[5] pattern with the\n-`working-tree-encoding` attribute.  For example, the following pattern sets all\n+`working-tree-encoding` attribute. For example, the following pattern sets all\n C files to use UTF-16LE-BOM, which is a common encoding on Windows:\n +\n ----\n *.c\tworking-tree-encoding=UTF-16LE-BOM\n ----\n +\n-You will need to run `git add --renormalize` to have this take effect.  Note\n+You will need to run `git add --renormalize` to have this take effect. Note\n that if you are making these changes on a project that is used across platforms,\n you'll probably want to make it in a per-user configuration file or in the one\n in `$GIT_DIR/info/attributes`, since making it in a `.gitattributes` file in the\n@@ -279,13 +279,13 @@ and see linkgit:gitattributes[5] for more information about attribute files.\n \n [[windows-diff-control-m]]\n I'm on Windows and git diff shows my files as having a `^M` at the end.::\n-\tBy default, Git expects files to be stored with Unix line endings.  As such,\n+\tBy default, Git expects files to be stored with Unix line endings. As such,\n \tthe carriage return (`^M`) that is part of a Windows line ending is shown\n-\tbecause it is considered to be trailing whitespace.  Git defaults to showing\n+\tbecause it is considered to be trailing whitespace. Git defaults to showing\n \ttrailing whitespace only on new lines, not existing ones.\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+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 +\n@@ -295,28 +295,28 @@ don't wish to remove the carriage returns from your line endings.\n [[recommended-storage-settings]]\n What's the recommended way to store files in Git?::\n \tWhile Git can store and handle any file of any type, there are some\n-\tsettings that work better than others.  In general, we recommend that\n+\tsettings that work better than others. In general, we recommend that\n \ttext files be stored in UTF-8 without a byte-order mark (BOM) with LF\n-\t(Unix-style) endings.  We also recommend the use of UTF-8 (again,\n-\twithout BOM) in commit messages.  These are the settings that work best\n+\t(Unix-style) endings. We also recommend the use of UTF-8 (again,\n+\twithout BOM) in commit messages. These are the settings that work best\n \tacross platforms and with tools such as `git diff` and `git merge`.\n +\n Additionally, if you have a choice between storage formats that are text based\n or non-text based, we recommend storing files in the text format and, if\n-necessary, transforming them into the other format.  For example, a text-based\n+necessary, transforming them into the other format. For example, a text-based\n SQL dump with one record per line will work much better for diffing and merging\n-than an actual database file.  Similarly, text-based formats such as Markdown\n+than an actual database file. Similarly, text-based formats such as Markdown\n and AsciiDoc will work better than binary formats such as Microsoft Word and\n PDF.\n +\n Similarly, storing binary dependencies (e.g., shared libraries or JAR files) or\n-build products in the repository is generally not recommended.  Dependencies and\n+build products in the repository is generally not recommended. Dependencies and\n build products are best stored on an artifact or package server with only\n 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+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 +\n ----\n-- \n2.20.1\n\n"},{"id":"394875","messageId":"20200406181216.5340-3-shouryashukla.oo@gmail.com","threadId":"53172","inReplyTo":"20200406181216.5340-1-shouryashukla.oo@gmail.com","subject":"[PATCH 2/2] gitfaq: append the 'Common Issues' section","fromName":"Shourya Shukla","fromEmail":"shouryashukla.oo@gmail.com","sentAt":"2020-04-06T18:12:16Z","receivedAt":"2020-04-06T18:12:38Z","isPatch":true,"sender":{"key":"shouryashukla.oo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43680618?v=4"},"body":"Add more issues and their respective solutions in the 'Common Issues'\nsection of gitfaq.\n\nSigned-off-by: Shourya Shukla <shouryashukla.oo@gmail.com>\n---\n Documentation/gitfaq.txt | 72 ++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 72 insertions(+)\n\ndiff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\nindex 3ca16b1092..ccc14774ba 100644\n--- a/Documentation/gitfaq.txt\n+++ b/Documentation/gitfaq.txt\n@@ -223,6 +223,78 @@ a file checked into the repository which is a template or set of defaults which\n can then be copied alongside and modified as appropriate. This second, modified\n file is usually ignored to prevent accidentally committing it.\n \n+[[rebasing-and-merging]]\n+How do I know when to merge or rebase?::\n+\tRebasing and merging two entirely different concepts with different utiilites.\n+\tIn Git terms, rebasing means to place changes made in one branch over another branch\n+\t(called base, hence the term rebase). The commit history of the branch wanting to rebase\n+\tget placed over the branch on the receiving end and it appears as if those changes took\n+\tplace in the receiving branch itself. Merging, as the name suggests, merges the latest\n+\tcommit of one branch onto the recent branch, making this combination appear as one separate\n+\tcommit.\n++\n+As an additional tip, one can use interactive rebasing, `git rebase -i`, to perform rebasing\n+using a text editor GUI (the value of $GIT_EDITOR). Interactive rebase is an excellent utility\n+to perform various functions such as editing commit messages, dropping/squashing commits, editing\n+commits, etc. in one package.\n+\n+[[files-in-.gitignore-are-tracked]]\n+I asked Git to ignore various files, yet they show up as changes in my staging area::\n+\tOne uses `.gitignore` to ignore files from getting tracked in the working tree. This ignores\n+\tthe aforementioned files for the whole lifetime of the project unless they area removed from\n+\tthe `.gitignore`. But, `.gitignore` will only ignore the files which were not a part of the\n+\trepository when they were mentioned in the `.gitignore`. Hence, addition of a file to `.gitignore`\n+\tafter it was added to the working tree will have no effect and Git will keep tracking them.\n+\tTo prevent this from happening, one has to use `git rm --cached <file>` to remove the file\n+\tfrom the staging area(i.e. the cache) and not from the repository. \n+\n+[[changing-remote-of-the-repository]]\n+I want to change the remote of my repository. How do I do that?::\n+\tA remote is an identifier for a location to which Git pushes your changes as well as fetches\n+\tany new changes(if any). There might be different circumstances in which one might need to change\n+\tthe remote:\n+\t\t1. One might want to update the url of their remote; in that case, the command to use is,\n+\t\t   `git remote set-url <name> <newurl>`.\n+\n+\t\t2. One might want to have two different remotes for fetching and pushing; this generally\n+\t\t   happens in case of triangular workflows. In this case, it is advisable to create a\n+\t\t   separate remote just for fetching/pushing. But, another way can be to change the push\n+\t\t   url using the `--push` option in the `git set-url` command.\n+\n+[[fetching-and-pulling]]\n+How do I know if I want to do a fetch or a pull?::\n+\tA fetch brings in the latest changes made upstream(i.e. the remote repository we are working on).\n+\tThis allows us to inspect the changes made upstream and integrate all those changes(iff we want to)\n+\tor only cherry pick certain changes. Fetching does not have any immediate effects on the local\n+\trepository.\n+\n+\tA pull is a wrapper for a fetch and merge. This means that doing a `git pull` will not only fetch the\n+\tchanges made upstream but integrate them as well with our local repository. The merge may go smoothly\n+\tor have merge conflicts depending on the case. A pull does not allow you to review any changes made\n+\tupstream but rather merge those changes on their own.\n++\n+This is the reason why it is sometimes advised to fetch the changes first and then merge them accordingly\n+because not every change might be of utility to the user.\n+\n+[[checking-out]]\n+What is checking out a commit/branch? How do I perform one?::\n+\tIn Git terminology, checking out means updating the current working tree with a another commit or\n+\teven a separate tree(which would translate to a branch). This means that if I were to:\n+\t\t1. Go to another commit, to lets say modify stuff in that commit; I would be \"checking out\"\n+\t\t   to that commit and enter a \"detached HEAD\" state, meaning, that the \"pointer\" called HEAD\n+\t\t   which tells me where I am right now in my working tree is not where it generally should be,\n+\t\t   i.e., the latest commit(or the tip of the branch). I can now work upon the checked out\n+\t\t   commit and make any changes or just inspect the files at that state.\n+\n+\t\t2. Go to another branch or create another branch; I would be \"checking out\" to another tree\n+\t\t   in my local repository. One might expect to enter a detached HEAD here as well but in fact\n+\t\t   does not. This is because HEAD would point to the tip of the checked out branch, something\n+\t\t   which is not a characteristic of a detached HEAD.\n++\n+To checkout to a commit, one can either pass the SHA1 of the commit to be checked out or a reference to it wrt\n+the HEAD. To checkout to another already existing branch, one should use `git checkout <branch-name>`.\n+Also, one can create a new branch as well as checkout to it at the same time using `git checkout -b <new-branch-name>`.\n+\n Hooks\n -----\n \n-- \n2.20.1\n\n"},{"id":"394879","messageId":"xmqqzhbov3gy.fsf@gitster.c.googlers.com","threadId":"53172","inReplyTo":"20200406181216.5340-2-shouryashukla.oo@gmail.com","subject":"Re: [PATCH 1/2] gitfaq: cleanup gitfaq.txt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-06T19:06:21Z","receivedAt":"2020-04-06T19:06:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shourya Shukla <shouryashukla.oo@gmail.com> writes:\n\n> The file contained a lot of whitespace errors as well as some\n> grammatical mistakes. Amend them.\n>\n> Signed-off-by: Shourya Shukla <shouryashukla.oo@gmail.com>\n> ---\n>  Documentation/gitfaq.txt | 110 +++++++++++++++++++--------------------\n>  1 file changed, 55 insertions(+), 55 deletions(-)\n>\n> diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\n> index 1cf83df118..3ca16b1092 100644\n> --- a/Documentation/gitfaq.txt\n> +++ b/Documentation/gitfaq.txt\n> @@ -23,7 +23,7 @@ Configuration\n>  What should I put in `user.name`?::\n>  \tYou should put your personal name, generally a form using a given name\n>  \tand family name.  For example, the current maintainer of Git uses \"Junio\n> -\tC Hamano\".  This will be the name portion that is stored in every commit\n> +\tC Hamano\". This will be the name portion that is stored in every commit\n>  \tyou make.\n>  +\n>  This configuration doesn't have any effect on authenticating to remote services;\n> @@ -32,7 +32,7 @@ for that, see `credential.username` in linkgit:git-config[1].\n>  [[http-postbuffer]]\n>  What does `http.postBuffer` really do?::\n>  \tThis option changes the size of the buffer that Git uses when pushing\n> -\tdata to a remote over HTTP or HTTPS.  If the data is larger than this\n> +\tdata to a remote over HTTP or HTTPS. If the data is larger than this\n>  \tsize, libcurl, which handles the HTTP support for Git, will use chunked\n>  \ttransfer encoding since it isn't known ahead of time what the size of\n>  \tthe pushed data will be.\n> @@ -40,15 +40,15 @@ What does `http.postBuffer` really do?::\n>  Leaving this value at the default size is fine unless you know that either the\n>  remote server or a proxy in the middle doesn't support HTTP/1.1 (which\n>  introduced the chunked transfer encoding) or is known to be broken with chunked\n> -data.  This is often (erroneously) suggested as a solution for generic push\n> +data. This is often (erroneously) suggested as a solution for generic push\n>  problems, but since almost every server and proxy supports at least HTTP/1.1,\n> -raising this value usually doesn't solve most push problems.  A server or proxy\n> +raising this value usually doesn't solve most push problems. A server or proxy\n\nAll of the above look useless noise.  It's not like it is turning\nmultiple SP after full-stop into a single SP (there is one that is\nnot touched in the pre-context in the first hunk, for example)---\nnot that such a change is worth a churn.\n\nPlease split them out and concentrate on true errors and typoes;\notherwise it is too distracting and unreviewable.\n\nThanks.\n\n"},{"id":"394880","messageId":"xmqqv9mcv2fs.fsf@gitster.c.googlers.com","threadId":"53172","inReplyTo":"20200406181216.5340-3-shouryashukla.oo@gmail.com","subject":"Re: [PATCH 2/2] gitfaq: append the 'Common Issues' section","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-06T19:28:39Z","receivedAt":"2020-04-06T19:28:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shourya Shukla <shouryashukla.oo@gmail.com> writes:\n\n> +[[rebasing-and-merging]]\n> +How do I know when to merge or rebase?::\n> +\tRebasing and merging two entirely different concepts with different utiilites.\n\nCan you wrap these lines at a more reasonable column, like 65-72?\n\n> +\tIn Git terms, rebasing means to place changes made in one branch over another branch\n> +\t(called base, hence the term rebase). The commit history of the branch wanting to rebase\n> +\tget placed over the branch on the receiving end and it appears as if those changes took\n> +\tplace in the receiving branch itself. Merging, as the name suggests, merges the latest\n> +\tcommit of one branch onto the recent branch, making this combination appear as one separate\n> +\tcommit.\n\nThere is nothing technically wrong per-se in the above, but is this\nworth saying here, instead of polishing the tutorial or rebase/merge\nmanual pages?  Also, in the above, I do not see much that would help\nreaders to decide which one between merge and rebase to choose.\n\n> +[[files-in-.gitignore-are-tracked]]\n> +I asked Git to ignore various files, yet they show up as changes in my staging area::\n> +\tOne uses `.gitignore` to ignore files from getting tracked in the working tree. This ignores\n> +\tthe aforementioned files for the whole lifetime of the project unless they area removed from\n> +\tthe `.gitignore`.\n\nThis should mention \"git add\" (and possibly \"git status\") somewhere.\nYou list patterns to match cruft you want to \"IGNORE\", (i.e. would\nnot want to track), so that \"git add .\" would ignore it, and \"git\nstatus\" won't make noises about them not being tracked.\n\n> But, `.gitignore` will only ignore the files which were not a part of the\n> +\trepository when they were mentioned in the `.gitignore`. Hence, addition of a file to `.gitignore`\n> +\tafter it was added to the working tree will have no effect and Git will keep tracking them.\n> +\tTo prevent this from happening, one has to use `git rm --cached <file>` to remove the file\n> +\tfrom the staging area(i.e. the cache) and not from the repository. \n\nThat's not \"prevent this from happening\".  It is more like\nrecovering from an earlier mistake of adding what you did not want\nto add.\n\nBut people ask \".gitignore does not ignore, my vendor.o file is\ntracked, and I want changes to vendor.o to be ignored\" in the\ncontext of \"once tracked, .gitignore would ont kick in\", so the\nabove advice to \"remove from the tracked set\" would not even help\nthem.  Their expectation needs to be adjusted, and an entry in FAQ\nyou are trying to add is a good place to do so.\n\n> +[[checking-out]]\n> +What is checking out a commit/branch? How do I perform one?::\n> +\tIn Git terminology, checking out means updating the current working tree with a another commit or\n> +\teven a separate tree(which would translate to a branch).\n\nUnless you are going to mention \"switch\" and \"restore\", you should\nstress the fact that \"checkout\" checks out two separate things for\ntwo different purposes upfront, in the first sentence.\n\n - Checking out a branch (or a commit) is to set up the working tree\n   files in preparation for working on the history of the branch\n   (most often, to grow the history by adding more commits, but\n   sometimes to edit the history by rebasing).\n\n - Checking out individual paths out of a tree-ish (most often, a\n   commit) is to grab a verbatim copy of the path recorded in the\n   tree-ish to update the files in the working tree, and is done to\n   work on the history of the current branch.\n\nPeople found the \"checkout\" command confusing, as the distinction\nbetween the two weren't clearly taught to them.  More recent\nversions of Git introduced \"switch\" and \"restore\" subcommands that\ncan be used only for the former and for the latter purpose,\nrespectively.\n\nThanks.\n"},{"id":"394895","messageId":"xmqqy2r8tbxn.fsf@gitster.c.googlers.com","threadId":"53172","inReplyTo":"20200406181216.5340-2-shouryashukla.oo@gmail.com","subject":"Re: [PATCH 1/2] gitfaq: cleanup gitfaq.txt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-06T23:46:28Z","receivedAt":"2020-04-06T23:46:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shourya Shukla <shouryashukla.oo@gmail.com> writes:\n\n[jc: All other changes in 1/2 turned out to be removal of SP when\nthere were dot-SP-SP at the end of a sentence, which I am omitted\nhere as they were so distracting.]\n\n> -Such a shell command can be specified by starting the option value with an\n> -exclamation point.  If your password or token were stored in the `GIT_TOKEN`,\n> +Such a shell command can be specified by putting an exclamation point before\n> +the option. If your password or token were stored in the `GIT_TOKEN`,\n>  you could run the following command to set your credential helper:\n\nSorry, but I am not sure how this change is an improvement.  It is\nnot making it worse, but it is not making it any better, at least to\nme.\n\n> -How do I ignore changes to a tracked file?::\n> -\tGit doesn't provide a way to do this.  The reason is that if Git needs\n> +How do I ignore changes made to a tracked file?::\n> +\tGit doesn't provide a way to do this. The reason is that if Git needs\n\nAh, strike what I said about your new section on \".gitignore\"; this\nis already the right place to describe it.\n\nWith or without 'made', I think the header says the same thing, but\nI guess it does not hurt to be explicit.\n\nBy the way, if you still want to pursue \"full-stop at the end of the\nsentence MUST be followed by no more than one SP\", I won't stop you,\nbut please do so in a separate patch that has NO OTHER CHANGES.\nThey drown other changes out that are not mechanical and makes them\nhard to review.\n\nThanks.\n"},{"id":"394899","messageId":"20200407010709.GK6369@camp.crustytoothpaste.net","threadId":"53172","inReplyTo":"xmqqy2r8tbxn.fsf@gitster.c.googlers.com","subject":"Re: [PATCH 1/2] gitfaq: cleanup gitfaq.txt","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-04-07T01:07:09Z","receivedAt":"2020-04-07T01:07:17Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-04-06 at 23:46:28, Junio C Hamano wrote:\n> Shourya Shukla <shouryashukla.oo@gmail.com> writes:\n> \n> > -How do I ignore changes to a tracked file?::\n> > -\tGit doesn't provide a way to do this.  The reason is that if Git needs\n> > +How do I ignore changes made to a tracked file?::\n> > +\tGit doesn't provide a way to do this. The reason is that if Git needs\n> \n> With or without 'made', I think the header says the same thing, but\n> I guess it does not hurt to be explicit.\n\nI'm fine with or without this change.  I think the original is clear to\na native English speaker, but if we think it will be easier to parse or\nharder to misread with \"made\", then I'm in favor of the change.  I, of\ncourse, cannot speak for how either one reads to a non-native speaker.\n\nI'm not sure it's fair to categorize it as a \"grammatical mistake\",\nthough.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"394903","messageId":"xmqqtv1wt29v.fsf@gitster.c.googlers.com","threadId":"53172","inReplyTo":"20200407010709.GK6369@camp.crustytoothpaste.net","subject":"Re: [PATCH 1/2] gitfaq: cleanup gitfaq.txt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-07T03:15:08Z","receivedAt":"2020-04-07T03:15:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> I'm fine with or without this change.  I think the original is clear to\n> a native English speaker, but if we think it will be easier to parse or\n> harder to misread with \"made\", then I'm in favor of the change.  I, of\n> course, cannot speak for how either one reads to a non-native speaker.\n\nI am not a native, but if I were writing it I would probably have\nwritten without the \"made\", so I guess I am in slight favor of not\nchanging this part.\n\n> I'm not sure it's fair to categorize it as a \"grammatical mistake\",\n> though.\n\nThe patch certainly is an attempt to make the text better, but I\nagree that the patch does not correct any \"mistake\".\n\nThanks.\n"},{"id":"395079","messageId":"20200408182247.jz5xnlw3sbrazq36@yadavpratyush.com","threadId":"53172","inReplyTo":"xmqqy2r8tbxn.fsf@gitster.c.googlers.com","subject":"Re: [PATCH 1/2] gitfaq: cleanup gitfaq.txt","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2020-04-08T18:22:47Z","receivedAt":"2020-04-08T18:23:00Z","isPatch":true,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 06/04/20 04:46PM, Junio C Hamano wrote:\n> Shourya Shukla <shouryashukla.oo@gmail.com> writes:\n> \n> By the way, if you still want to pursue \"full-stop at the end of the\n> sentence MUST be followed by no more than one SP\", I won't stop you,\n> but please do so in a separate patch that has NO OTHER CHANGES.\n> They drown other changes out that are not mechanical and makes them\n> hard to review.\n\nMaybe we should just have a consistent convention throughout the \ndocumentation on whether to use one space after a full-stop or two. \nRight now in some places we use one space, in some others we use two, \neven in the same file. This is slightly distracting when reading. Having \na convention would at least result in uniformity, even if it won't end \nthe debate on which is better. And FWIW, our man pages are always \nrendered with one space, even if the source file has two.\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"395229","messageId":"xmqqblnzjitv.fsf@gitster.c.googlers.com","threadId":"53172","inReplyTo":"20200408182247.jz5xnlw3sbrazq36@yadavpratyush.com","subject":"Re: [PATCH 1/2] gitfaq: cleanup gitfaq.txt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-10T18:29:00Z","receivedAt":"2020-04-10T18:29:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pratyush Yadav <me@yadavpratyush.com> writes:\n\n> Maybe we should just have a consistent convention throughout the \n> documentation on whether to use one space after a full-stop or two. \n> Right now in some places we use one space, in some others we use two, \n> even in the same file. This is slightly distracting when reading.\n\nAs somebody who almost always goes to the source on a fixed width\nfont terminal and not to formatted output, I personally find it\ndistracting not to have the extra space at the end of a sentence.\n\n> And FWIW, our man pages are always \n> rendered with one space, even if the source file has two.\n\nOr three, for that matter ;-)\n\nIt is one of the reasons why we didn't really care and have not gone\nchurning the source.\n\n> Having a convention would at least result in uniformity, even if\n> it won't end the debate on which is better.\n\nYup.  If I were to dictate a convention, I'd say we should have one\nextra space after a full-stop or similar that ends a sentence.\n\nAs you pointed out, the choice of the convention does not make any\ndifference to the end product for end users, and only affect those\nwho work on the source with mark-ups, that is a fairly easy thing\nto declare, without letting anybody argue for or against---it is not\nbetter or worse than the other choice, but choosing one and sticking\nto it is probably much better than not having a uniform convention.\n\nHaving said that, let's not go berserk and start reformatting,\nespecially areas that are actively touched for non-stylistic\nreasons.  Those other changes are much much more important.\n\nThanks.\n"}]}