![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index ce197d59f4b75a93238ccb5c219fbab63f6d5858..059c8ffd272051792f0949a8dc224165d03a1799 100644 (file)
that it has noticed that "hello" has been modified, and that the old object
contents it had have been replaced with something else.
-To make it readable, we can tell git-diff-files to output the
+To make it readable, we can tell `git-diff-files` to output the
differences as a patch, using the `-p` flag:
------------
tree was all about, along with information of how we came to that state.
Creating a tree object is trivial, and is done with `git-write-tree`.
-There are no options or other input: git write-tree will take the
+There are no options or other input: `git write-tree` will take the
current index state, and write an object that describes that whole
index. In other words, we're now tying together all the different
filenames with their contents (and their permissions), and we're
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>
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`.
up-to-date (so that you don't have to refresh it afterward), and the
`-a` flag means "check out all files" (if you have a stale copy or an
older version of a checked out tree you may also need to add the `-f`
-flag first, to tell git-checkout-index to *force* overwriting of any old
+flag first, to tell `git-checkout-index` to *force* overwriting of any old
files).
Again, this can all be simplified with
================================================
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
------------
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.
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:
------------
which will very loudly warn you that you're now committing a merge
(which is correct, so never mind), and you can write a small merge
-message about your adventures in git-merge-land.
+message about your adventures in `git-merge`-land.
After you're done, start up `gitk \--all` to see graphically what the
history looks like. Notice that `mybranch` still exists, and you can
before the commit log message is a short name you can use to
name the commit. In the above example, 'master' and 'mybranch'
are branch heads. 'master^' is the first parent of 'master'
-branch head. Please see 'git-rev-parse' documentation if you
+branch head. Please see linkgit:git-rev-parse[1] if you want to
see more complex cases.
[NOTE]
-Without the '--more=1' option, 'git-show-branch' would not output the
+Without the '--more=1' option, `git-show-branch` would not output the
'[master^]' commit, as '[mybranch]' commit is a common ancestor of
-both 'master' and 'mybranch' tips. Please see 'git-show-branch'
-documentation for details.
+both 'master' and 'mybranch' tips. Please see linkgit:git-show-branch[1]
+for details.
[NOTE]
If there were more commits on the 'master' branch after the merge, the
-merge commit itself would not be shown by 'git-show-branch' by
+merge commit itself would not be shown by `git-show-branch` by
default. You would need to provide '--sparse' option to make the
merge commit visible in this case.
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>
[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
$ 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.
+* [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.
------------
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:
------------
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.
------------
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'):
------------