{"thread":{"id":"53216","subject":"[PATCH v2 0/1] update gitfaq","startedAt":"2020-04-13T13:17:25Z","lastAt":"2020-04-13T17:05:29Z","messageCount":2,"participants":["Shourya Shukla"],"isPatch":true,"patchVersion":2,"patchTotal":1},"messages":[{"id":"395332","messageId":"20200413105529.16693-1-shouryashukla.oo@gmail.com","threadId":"53216","inReplyTo":null,"subject":"[PATCH v2 0/1] update gitfaq","fromName":"Shourya Shukla","fromEmail":"shouryashukla.oo@gmail.com","sentAt":"2020-04-13T10:55:28Z","receivedAt":"2020-04-13T13:17:25Z","isPatch":true,"sender":{"key":"shouryashukla.oo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43680618?v=4"},"body":"Hello,\n\nThank you Junio and Brian for reviewing my patch :)\nhttps://lore.kernel.org/git/20200406181216.5340-1-shouryashukla.oo@gmail.com/\n\nThe changes in this version are:\n\t1. Dropped the gitfaq cleanup patch.\n\t2. Improved the 'rebasing and merging' section. Added information on when to rebase/merge.\n\t3. Improved the 'files-in-.gitignore-are-tracked' section. Added significance of `git add` & `git status`.\n\t4. Improved the 'checking-out' section. Added more description in use cases of `git checkout` as well as introduced\n\t   `git switch` and `git restore`.\n\t5. Improvements in sentence formation and the terms used.\n\nRegards,\nShourya Shukla\n\nShourya Shukla (1):\n  gitfaq: append the 'Common Issues' section\n\n Documentation/gitfaq.txt | 104 +++++++++++++++++++++++++++++++++++++++\n 1 file changed, 104 insertions(+)\n\n-- \n2.20.1\n\n"},{"id":"395361","messageId":"20200413105529.16693-2-shouryashukla.oo@gmail.com","threadId":"53216","inReplyTo":"20200413105529.16693-1-shouryashukla.oo@gmail.com","subject":"[PATCH v2 1/1] gitfaq: append the 'Common Issues' section","fromName":"Shourya Shukla","fromEmail":"shouryashukla.oo@gmail.com","sentAt":"2020-04-13T10:55:29Z","receivedAt":"2020-04-13T17:05:29Z","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 | 104 +++++++++++++++++++++++++++++++++++++++\n 1 file changed, 104 insertions(+)\n\ndiff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt\nindex 1cf83df118..fc261cbbf5 100644\n--- a/Documentation/gitfaq.txt\n+++ b/Documentation/gitfaq.txt\n@@ -223,6 +223,110 @@ 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+Now that we have an idea of the key differences between merging and rebasing, we can look at the\n+circumstances when we would want to perform them. Generally, merging is preferred when one desires\n+to create a new feature, perform its integration testing with the original codebase, and finally\n+integrate it if all tests are passed. One would choose to create a separate branch for this purpose\n+and maybe dissolve it when the merge is done.\n++\n+One might want to perform a rebase when they intend to retain the changes made in a separate branch\n+into their original branch. In that case, a rebase would place the former changes onto the commit tree\n+of the latter.\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., all 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'. Consequently, `git add` does not list these files as 'modified' even if any\n+\tchange was made in them and `git status` does not bother to track the changes in these files\n+\teither.\n+\n+\tBut, '.gitignore' will only ignore the files which were not a part of the repository when they\n+\twere mentioned in the it. Hence, addition of a file to '.gitignore' after it was added to the\n+\tworking tree will have no effect and Git will keep tracking them. To amend this mistake, i.e.,\n+\tto untrack and completely ignore a tracked file, one has to use `git rm --cached <file>` to\n+\tremove the file from the staging area(i.e. the cache) and not from the repository(presuming\n+\tthe file has been added in the 'gitignore'). This will hence make our file behave exactly like\n+\twe described in the paragraph above.\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+\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, a 'checkout' serves three purposes, namely:\n+\n+\t\t1. Go to another commit; I would be \"checking out\" to that commit and enter a \"detached HEAD\"\n+\t\t   state, meaning, that the \"pointer\" called HEAD which tells me where I am right now in my\n+\t\t   working tree is not where it generally should be, i.e., referring to a named branch(say, master).\n+\t\t   Instead the aforementioned pointer is referring to the specified commit. I can now work upon the\n+\t\t   checked out commit and make any changes or just inspect the files at that state.\n+\n+\t\t2. Go to a different version of a particular file; let's say I want to go to a particular version\n+\t\t   of a file in my working tree. I can again \"checkout\" to that particular version(i.e., going to a\n+\t\t   particular commit where certain changes were made). This can be done by entering the SHA1 of the\n+\t\t   commit in question. \n+\n+\t\t3. 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.\t\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 w.r.t.\n+the HEAD. To checkout to a particular version of a file, one can use `git checkout <SHA1/reference> <file>`.\n+To checkout to an already existing branch, one should use `git checkout <branch-name>`. To simultaneously create\n+and checkout to a branch, one can use the `-b` option in the aforementioned command.\n++\n+One can observe how versatile the checkout command is, yet due to simplify things even further, two commands were\n+introduced in version 2.23 of Git so as to break down the functionalities of `git checkout` and make it learning\n+the command easier for a beginner. The commands being `git switch` and `git restore`.\n++\n+`git restore` combines the first two features of the checkout as well as functionalities of `git reset` and `git revert`\n+at one place so as to improve the functionality of the command.\n++\n+`git switch` perfoms the third functionality of the `git checkout` command, i.e., manipulating branches(creation).\n+\n Hooks\n -----\n \n-- \n2.20.1\n\n"}]}