undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

user manual: answer some comments from Junio

Browse Source 
Junio left a few comments in his previous patch; deal with
each of them.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
This commit is contained in:
J. Bruce Fields 2007-01-10 23:23:37 -05:00
parent eb6ae7f4ad
commit 01997b4a25
1 changed files with 10 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
Documentation/user-manual.txt
View File

@ -863,17 +863,10 @@ times as you want: in order to keep track of what you want committed
at step 3, git maintains a snapshot of the tree's contents in a
special staging area called "the index."
By default, the content of the index is identical to that of the
HEAD. The command "git diff --cached" shows the difference between
HEAD and the index, so you should no output from that command.
////////////////////////////////////////////////
This is talking about not "by default", but "when you start
out". The last sentence does not parse for me...
////////////////////////////////////////////////
At the beginning, the content of the index will be identical to
that of the HEAD. The command "git diff --cached", which shows
the difference between the HEAD and the index, should therefore
produce no output at that point.
Modifying the index is easy:
@ -1337,20 +1330,14 @@ single mailbox file, say "patches.mbox", then run
$ git am -3 patches.mbox
-------------------------------------------------
////////////////////////////////////////////////
If you allow git-am to fall back to 3-way merge with -3, you
would see conflicts and "resolving a merge" techniques apply.
Otherwise "conflicts" will just fail the patch and your working
tree and index are left untouched.
////////////////////////////////////////////////
Git will apply each patch in order; if any conflicts are found, it
will stop, and you can fix the conflicts as described in
"<<resolving-a-merge,Resolving a merge>>". Once the index is updated
with the results of the conflict resolution, instead of creating a
new commit, just run
"<<resolving-a-merge,Resolving a merge>>". (The "-3" option tells
git to perform a merge; if you would prefer it just to abort and
leave your tree and index untouched, you may omit that option.)
Once the index is updated with the results of the conflict
resolution, instead of creating a new commit, just run
-------------------------------------------------
$ git am --resolved