diff options
Diffstat (limited to 'Documentation/tutorial.txt')
| -rw-r--r-- | Documentation/tutorial.txt | 48 |
1 files changed, 24 insertions, 24 deletions
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt index c27a4505d..5fc5be5a2 100644 --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -16,8 +16,8 @@ public email address before doing any operation. The easiest way to do so is: ------------------------------------------------ -$ git repo-config --global user.name "Your Name Comes Here" -$ git repo-config --global user.email you@yourdomain.example.com +$ git config --global user.name "Your Name Comes Here" +$ git config --global user.email you@yourdomain.example.com ------------------------------------------------ @@ -101,27 +101,27 @@ want to commit together. This can be done in a few different ways: 1) By using 'git add <file_spec>...' - This can be performed multiple times before a commit. Note that this - is not only for adding new files. Even modified files must be - added to the set of changes about to be committed. The "git status" - command gives you a summary of what is included so far for the - next commit. When done you should use the 'git commit' command to - make it real. +This can be performed multiple times before a commit. Note that this +is not only for adding new files. Even modified files must be +added to the set of changes about to be committed. The "git status" +command gives you a summary of what is included so far for the +next commit. When done you should use the 'git commit' command to +make it real. - Note: don't forget to 'add' a file again if you modified it after the - first 'add' and before 'commit'. Otherwise only the previous added - state of that file will be committed. This is because git tracks - content, so what you're really 'add'ing to the commit is the *content* - of the file in the state it is in when you 'add' it. +Note: don't forget to 'add' a file again if you modified it after the +first 'add' and before 'commit'. Otherwise only the previous added +state of that file will be committed. This is because git tracks +content, so what you're really 'add'ing to the commit is the *content* +of the file in the state it is in when you 'add' it. 2) By using 'git commit -a' directly - This is a quick way to automatically 'add' the content from all files - that were modified since the previous commit, and perform the actual - commit without having to separately 'add' them beforehand. This will - not add content from new files i.e. files that were never added before. - Those files still have to be added explicitly before performing a - commit. +This is a quick way to automatically 'add' the content from all files +that were modified since the previous commit, and perform the actual +commit without having to separately 'add' them beforehand. This will +not add content from new files i.e. files that were never added before. +Those files still have to be added explicitly before performing a +commit. But here's a twist. If you do 'git commit <file1> <file2> ...' then only the changes belonging to those explicitly specified files will be @@ -353,12 +353,12 @@ repository in the repository configuration, and that location is used for pulls: ------------------------------------- -$ git repo-config --get remote.origin.url +$ git config --get remote.origin.url /home/bob/myrepo ------------------------------------- (The complete configuration created by git-clone is visible using -"git repo-config -l", and the gitlink:git-repo-config[1] man page +"git config -l", and the gitlink:git-config[1] man page explains the meaning of each option.) Git also keeps a pristine copy of Alice's master branch under the @@ -458,9 +458,9 @@ $ git reset --hard HEAD^ # reset your current branch and working Be careful with that last command: in addition to losing any changes in the working directory, it will also remove all later commits from this branch. If this branch is the only branch containing those -commits, they will be lost. (Also, don't use "git reset" on a -publicly-visible branch that other developers pull from, as git will -be confused by history that disappears in this way.) +commits, they will be lost. Also, don't use "git reset" on a +publicly-visible branch that other developers pull from, as it will +force needless merges on other developers to clean up the history. The git grep command can search for strings in any version of your project, so |