Documentation: more "git-" versus "git " changes

[thirdparty/git.git] / Documentation / gitcore-tutorial.txt

diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 7d721c5b084dd0e17c05d8fbd1758509d8146a1c..059c8ffd272051792f0949a8dc224165d03a1799 100644 (file)
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -595,7 +595,7 @@ pointer to the state you want to tag, but also a small tag name and
 message, along with optionally a PGP signature that says that yes,
 you really did
 that tag. You create these annotated tags with either the `-a` or
-`-s` flag to `git tag`:
+`-s` flag to `git-tag`:
 
 ----------------
 $ git tag -s <tagname>
@@ -642,7 +642,7 @@ and it will be gone. There's no external repository, and there's no
 history outside the project you created.
 
  - if you want to move or duplicate a git repository, you can do so. There
-   is `git clone` command, but if all you want to do is just to
+   is `git-clone` command, but if all you want to do is just to
    create a copy of your repository (with all the full history that
    went along with it), you can do so with a regular
    `cp -a git-tutorial new-git-tutorial`.
@@ -776,7 +776,7 @@ to it.
 ================================================
 If you make the decision to start your new branch at some
 other point in the history than the current `HEAD`, you can do so by
-just telling `git checkout` what the base of the checkout would be.
+just telling `git-checkout` what the base of the checkout would be.
 In other words, if you have an earlier tag or branch, you'd just do
 
 ------------
@@ -819,7 +819,7 @@ $ git branch <branchname> [startingpoint]
 
 which will simply _create_ the branch, but will not do anything further.
 You can then later -- once you decide that you want to actually develop
-on that branch -- switch to that branch with a regular `git checkout`
+on that branch -- switch to that branch with a regular `git-checkout`
 with the branchname as the argument.
 
 
@@ -881,7 +881,7 @@ source.
 Anyway, let's exit `gitk` (`^Q` or the File menu), and decide that we want
 to merge the work we did on the `mybranch` branch into the `master`
 branch (which is currently our `HEAD` too). To do that, there's a nice
-script called `git merge`, which wants to know which branches you want
+script called `git-merge`, which wants to know which branches you want
 to resolve and what the merge is all about:
 
 ------------
@@ -1023,12 +1023,12 @@ Merging external work
 It's usually much more common that you merge with somebody else than
 merging with your own branches, so it's worth pointing out that git
 makes that very easy too, and in fact, it's not that different from
-doing a `git merge`. In fact, a remote merge ends up being nothing
+doing a `git-merge`. In fact, a remote merge ends up being nothing
 more than "fetch the work from a remote repository into a temporary tag"
-followed by a `git merge`.
+followed by a `git-merge`.
 
 Fetching from a remote repository is done by, unsurprisingly,
-`git fetch`:
+`git-fetch`:
 
 ----------------
 $ git fetch <remote-repository>
@@ -1115,7 +1115,7 @@ argument.
 [NOTE]
 You could do without using any branches at all, by
 keeping as many local repositories as you would like to have
-branches, and merging between them with `git pull`, just like
+branches, and merging between them with `git-pull`, just like
 you merge between branches. The advantage of this approach is
 that it lets you keep a set of files for each `branch` checked
 out and you may find it easier to switch back and forth if you
@@ -1132,7 +1132,7 @@ like this:
 $ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
 ------------------------------------------------
 
-and use the "linus" keyword with `git pull` instead of the full URL.
+and use the "linus" keyword with `git-pull` instead of the full URL.
 
 Examples.
 
@@ -1168,7 +1168,7 @@ $ git show-branch --more=2 master mybranch
 +* [master^] Some fun.
 ------------
 
-Remember, before running `git merge`, our `master` head was at
+Remember, before running `git-merge`, our `master` head was at
 "Some fun." commit, while our `mybranch` head was at "Some
 work." commit.
 
@@ -1345,7 +1345,7 @@ $ mkdir my-git.git
 ------------
 
 Then, make that directory into a git repository by running
-`git init`, but this time, since its name is not the usual
+`git-init`, but this time, since its name is not the usual
 `.git`, we do things slightly differently:
 
 ------------
@@ -1407,7 +1407,7 @@ $ git repack
 
 will do it for you. If you followed the tutorial examples, you
 would have accumulated about 17 objects in `.git/objects/??/`
-directories by now. `git repack` tells you how many objects it
+directories by now. `git-repack` tells you how many objects it
 packed, and stores the packed file in `.git/objects/pack`
 directory.
 
@@ -1656,8 +1656,8 @@ $ git reset --hard master~2
 ------------
 
 You can make sure 'git show-branch' matches the state before
-those two 'git merge' you just did.  Then, instead of running
-two 'git merge' commands in a row, you would merge these two
+those two 'git-merge' you just did.  Then, instead of running
+two 'git-merge' commands in a row, you would merge these two
 branch heads (this is known as 'making an Octopus'):
 
 ------------