зеркало из https://github.com/microsoft/git.git
Merge branch 'ja/doc-style-fix'
Doc typo/stylo fixes. * ja/doc-style-fix: doc: tidy asciidoc style
This commit is contained in:
Junio C Hamano
Коммит
264def5ab7
|
|
@ -58,9 +58,9 @@ OPTIONS
|
|||
specifying `dir` will record not just a file `dir/file1`
|
||||
modified in the working tree, a file `dir/file2` added to
|
||||
the working tree, but also a file `dir/file3` removed from
|
||||
the working tree. Note that older versions of Git used
|
||||
the working tree). Note that older versions of Git used
|
||||
to ignore removed files; use `--no-all` option if you want
|
||||
to add modified or new files but ignore removed ones.
|
||||
to add modified or new files but ignore removed ones.
|
||||
+
|
||||
For more details about the <pathspec> syntax, see the 'pathspec' entry
|
||||
in linkgit:gitglossary[7].
|
||||
|
|
@ -124,7 +124,7 @@ subdirectories).
|
|||
--no-ignore-removal::
|
||||
Update the index not only where the working tree has a file
|
||||
matching <pathspec> but also where the index already has an
|
||||
entry. This adds, modifies, and removes index entries to
|
||||
entry. This adds, modifies, and removes index entries to
|
||||
match the working tree.
|
||||
+
|
||||
If no <pathspec> is given when `-A` option is used, all
|
||||
|
|
@ -206,7 +206,7 @@ EXAMPLES
|
|||
--------
|
||||
|
||||
* Adds content from all `*.txt` files under `Documentation` directory
|
||||
and its subdirectories:
|
||||
and its subdirectories:
|
||||
+
|
||||
------------
|
||||
$ git add Documentation/\*.txt
|
||||
|
|
|
|||
|
|
@ -297,7 +297,7 @@ $ git checkout my2.6.14
|
|||
------------
|
||||
+
|
||||
<1> This step and the next one could be combined into a single step with
|
||||
"checkout -b my2.6.14 v2.6.14".
|
||||
"checkout -b my2.6.14 v2.6.14".
|
||||
|
||||
Delete an unneeded branch::
|
||||
+
|
||||
|
|
@ -309,10 +309,10 @@ $ git branch -D test <2>
|
|||
------------
|
||||
+
|
||||
<1> Delete the remote-tracking branches "todo", "html" and "man". The next
|
||||
'fetch' or 'pull' will create them again unless you configure them not to.
|
||||
See linkgit:git-fetch[1].
|
||||
'fetch' or 'pull' will create them again unless you configure them not to.
|
||||
See linkgit:git-fetch[1].
|
||||
<2> Delete the "test" branch even if the "master" branch (or whichever branch
|
||||
is currently checked out) does not have all commits from the test branch.
|
||||
is currently checked out) does not have all commits from the test branch.
|
||||
|
||||
|
||||
NOTES
|
||||
|
|
|
|||
|
|
@ -424,14 +424,14 @@ $ git tag foo <3>
|
|||
------------
|
||||
|
||||
<1> creates a new branch 'foo', which refers to commit 'f', and then
|
||||
updates HEAD to refer to branch 'foo'. In other words, we'll no longer
|
||||
be in detached HEAD state after this command.
|
||||
updates HEAD to refer to branch 'foo'. In other words, we'll no longer
|
||||
be in detached HEAD state after this command.
|
||||
|
||||
<2> similarly creates a new branch 'foo', which refers to commit 'f',
|
||||
but leaves HEAD detached.
|
||||
but leaves HEAD detached.
|
||||
|
||||
<3> creates a new tag 'foo', which refers to commit 'f',
|
||||
leaving HEAD detached.
|
||||
leaving HEAD detached.
|
||||
|
||||
If we have moved away from commit 'f', then we must first recover its object
|
||||
name (typically by using git reflog), and then we can create a reference to
|
||||
|
|
@ -459,8 +459,8 @@ EXAMPLES
|
|||
--------
|
||||
|
||||
. The following sequence checks out the `master` branch, reverts
|
||||
the `Makefile` to two revisions back, deletes hello.c by
|
||||
mistake, and gets it back from the index.
|
||||
the `Makefile` to two revisions back, deletes hello.c by
|
||||
mistake, and gets it back from the index.
|
||||
+
|
||||
------------
|
||||
$ git checkout master <1>
|
||||
|
|
@ -494,7 +494,7 @@ $ git checkout -- hello.c
|
|||
------------
|
||||
|
||||
. After working in the wrong branch, switching to the correct
|
||||
branch would be done using:
|
||||
branch would be done using:
|
||||
+
|
||||
------------
|
||||
$ git checkout mytopic
|
||||
|
|
@ -522,7 +522,7 @@ registered in your index file, so `git diff` would show you what
|
|||
changes you made since the tip of the new branch.
|
||||
|
||||
. When a merge conflict happens during switching branches with
|
||||
the `-m` option, you would see something like this:
|
||||
the `-m` option, you would see something like this:
|
||||
+
|
||||
------------
|
||||
$ git checkout -m mytopic
|
||||
|
|
|
|||
|
|
@ -213,16 +213,16 @@ $ git reset --merge ORIG_HEAD <3>
|
|||
$ git cherry-pick -Xpatience topic^ <4>
|
||||
------------
|
||||
<1> apply the change that would be shown by `git show topic^`.
|
||||
In this example, the patch does not apply cleanly, so
|
||||
information about the conflict is written to the index and
|
||||
working tree and no new commit results.
|
||||
In this example, the patch does not apply cleanly, so
|
||||
information about the conflict is written to the index and
|
||||
working tree and no new commit results.
|
||||
<2> summarize changes to be reconciled
|
||||
<3> cancel the cherry-pick. In other words, return to the
|
||||
pre-cherry-pick state, preserving any local modifications you had in
|
||||
the working tree.
|
||||
pre-cherry-pick state, preserving any local modifications
|
||||
you had in the working tree.
|
||||
<4> try to apply the change introduced by `topic^` again,
|
||||
spending extra time to avoid mistakes based on incorrectly matching
|
||||
context lines.
|
||||
spending extra time to avoid mistakes based on incorrectly
|
||||
matching context lines.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -132,9 +132,9 @@ $ git diff HEAD <3>
|
|||
+
|
||||
<1> Changes in the working tree not yet staged for the next commit.
|
||||
<2> Changes between the index and your last commit; what you
|
||||
would be committing if you run "git commit" without "-a" option.
|
||||
would be committing if you run "git commit" without "-a" option.
|
||||
<3> Changes in the working tree since your last commit; what you
|
||||
would be committing if you run "git commit -a"
|
||||
would be committing if you run "git commit -a"
|
||||
|
||||
Comparing with arbitrary commits::
|
||||
+
|
||||
|
|
@ -145,10 +145,10 @@ $ git diff HEAD^ HEAD <3>
|
|||
------------
|
||||
+
|
||||
<1> Instead of using the tip of the current branch, compare with the
|
||||
tip of "test" branch.
|
||||
tip of "test" branch.
|
||||
<2> Instead of comparing with the tip of "test" branch, compare with
|
||||
the tip of the current branch, but limit the comparison to the
|
||||
file "test".
|
||||
the tip of the current branch, but limit the comparison to the
|
||||
file "test".
|
||||
<3> Compare the version before the last commit and the last commit.
|
||||
|
||||
Comparing branches::
|
||||
|
|
@ -162,7 +162,7 @@ $ git diff topic...master <3>
|
|||
<1> Changes between the tips of the topic and the master branches.
|
||||
<2> Same as above.
|
||||
<3> Changes that occurred on the master branch since when the topic
|
||||
branch was started off it.
|
||||
branch was started off it.
|
||||
|
||||
Limiting the diff output::
|
||||
+
|
||||
|
|
@ -173,9 +173,9 @@ $ git diff arch/i386 include/asm-i386 <3>
|
|||
------------
|
||||
+
|
||||
<1> Show only modification, rename, and copy, but not addition
|
||||
or deletion.
|
||||
or deletion.
|
||||
<2> Show only names and the nature of change, but not actual
|
||||
diff output.
|
||||
diff output.
|
||||
<3> Limit diff output to named subtrees.
|
||||
|
||||
Munging the diff output::
|
||||
|
|
@ -186,7 +186,7 @@ $ git diff -R <2>
|
|||
------------
|
||||
+
|
||||
<1> Spend extra cycles to find renames, copies and complete
|
||||
rewrites (very expensive).
|
||||
rewrites (very expensive).
|
||||
<2> Output diff in reverse.
|
||||
|
||||
SEE ALSO
|
||||
|
|
|
|||
|
|
@ -266,7 +266,7 @@ The `pu` branch will be updated even if it is does not fast-forward,
|
|||
because it is prefixed with a plus sign; `tmp` will not be.
|
||||
|
||||
* Peek at a remote's branch, without configuring the remote in your local
|
||||
repository:
|
||||
repository:
|
||||
+
|
||||
------------------------------------------------
|
||||
$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
|
||||
|
|
|
|||
|
|
@ -504,9 +504,9 @@ Toggle it to make sure it is set to `false`. Also, search for
|
|||
"mailnews.wraplength" and set the value to 0.
|
||||
|
||||
3. Disable the use of format=flowed:
|
||||
Edit..Preferences..Advanced..Config Editor. Search for
|
||||
"mailnews.send_plaintext_flowed".
|
||||
Toggle it to make sure it is set to `false`.
|
||||
Edit..Preferences..Advanced..Config Editor. Search for
|
||||
"mailnews.send_plaintext_flowed".
|
||||
Toggle it to make sure it is set to `false`.
|
||||
|
||||
After that is done, you should be able to compose email as you
|
||||
otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc),
|
||||
|
|
@ -629,14 +629,14 @@ EXAMPLES
|
|||
--------
|
||||
|
||||
* Extract commits between revisions R1 and R2, and apply them on top of
|
||||
the current branch using 'git am' to cherry-pick them:
|
||||
the current branch using 'git am' to cherry-pick them:
|
||||
+
|
||||
------------
|
||||
$ git format-patch -k --stdout R1..R2 | git am -3 -k
|
||||
------------
|
||||
|
||||
* Extract all commits which are in the current branch but not in the
|
||||
origin branch:
|
||||
origin branch:
|
||||
+
|
||||
------------
|
||||
$ git format-patch origin
|
||||
|
|
@ -645,7 +645,7 @@ $ git format-patch origin
|
|||
For each commit a separate file is created in the current directory.
|
||||
|
||||
* Extract all commits that lead to 'origin' since the inception of the
|
||||
project:
|
||||
project:
|
||||
+
|
||||
------------
|
||||
$ git format-patch --root origin
|
||||
|
|
@ -664,7 +664,7 @@ Note that non-Git "patch" programs won't understand renaming patches, so
|
|||
use it only when you know the recipient uses Git to apply your patch.
|
||||
|
||||
* Extract three topmost commits from the current branch and format them
|
||||
as e-mailable patches:
|
||||
as e-mailable patches:
|
||||
+
|
||||
------------
|
||||
$ git format-patch -3
|
||||
|
|
|
|||
|
|
@ -118,9 +118,9 @@ format is chosen. The following values are currently supported:
|
|||
|
||||
* "man": use the 'man' program as usual,
|
||||
* "woman": use 'emacsclient' to launch the "woman" mode in emacs
|
||||
(this only works starting with emacsclient versions 22),
|
||||
(this only works starting with emacsclient versions 22),
|
||||
* "konqueror": use 'kfmclient' to open the man page in a new konqueror
|
||||
tab (see 'Note about konqueror' below).
|
||||
tab (see 'Note about konqueror' below).
|
||||
|
||||
Values for other tools can be used if there is a corresponding
|
||||
`man.<tool>.cmd` configuration entry (see below).
|
||||
|
|
|
|||
|
|
@ -71,12 +71,12 @@ $ git p4 clone //depot/path/project
|
|||
------------
|
||||
This:
|
||||
|
||||
1. Creates an empty Git repository in a subdirectory called 'project'.
|
||||
1. Creates an empty Git repository in a subdirectory called 'project'.
|
||||
+
|
||||
2. Imports the full contents of the head revision from the given p4
|
||||
depot path into a single commit in the Git branch 'refs/remotes/p4/master'.
|
||||
2. Imports the full contents of the head revision from the given p4
|
||||
depot path into a single commit in the Git branch 'refs/remotes/p4/master'.
|
||||
+
|
||||
3. Creates a local branch, 'master' from this remote and checks it out.
|
||||
3. Creates a local branch, 'master' from this remote and checks it out.
|
||||
|
||||
To reproduce the entire p4 history in Git, use the '@all' modifier on
|
||||
the depot path:
|
||||
|
|
|
|||
|
|
@ -115,17 +115,17 @@ $ git pull git://info.example.com/ nitfol <4>
|
|||
------------
|
||||
+
|
||||
<1> You are happily working on something, and find the changes
|
||||
in these files are in good order. You do not want to see them
|
||||
when you run `git diff`, because you plan to work on other files
|
||||
and changes with these files are distracting.
|
||||
in these files are in good order. You do not want to see them
|
||||
when you run `git diff`, because you plan to work on other files
|
||||
and changes with these files are distracting.
|
||||
<2> Somebody asks you to pull, and the changes sound worthy of merging.
|
||||
<3> However, you already dirtied the index (i.e. your index does
|
||||
not match the `HEAD` commit). But you know the pull you are going
|
||||
to make does not affect `frotz.c` or `filfre.c`, so you revert the
|
||||
index changes for these two files. Your changes in working tree
|
||||
remain there.
|
||||
not match the `HEAD` commit). But you know the pull you are going
|
||||
to make does not affect `frotz.c` or `filfre.c`, so you revert the
|
||||
index changes for these two files. Your changes in working tree
|
||||
remain there.
|
||||
<4> Then you can pull and merge, leaving `frotz.c` and `filfre.c`
|
||||
changes still in the working tree.
|
||||
changes still in the working tree.
|
||||
|
||||
Undo a commit and redo::
|
||||
+
|
||||
|
|
@ -137,12 +137,12 @@ $ git commit -a -c ORIG_HEAD <3>
|
|||
------------
|
||||
+
|
||||
<1> This is most often done when you remembered what you
|
||||
just committed is incomplete, or you misspelled your commit
|
||||
message, or both. Leaves working tree as it was before "reset".
|
||||
just committed is incomplete, or you misspelled your commit
|
||||
message, or both. Leaves working tree as it was before "reset".
|
||||
<2> Make corrections to working tree files.
|
||||
<3> "reset" copies the old head to `.git/ORIG_HEAD`; redo the
|
||||
commit by starting with its log message. If you do not need to
|
||||
edit the message further, you can give `-C` option instead.
|
||||
commit by starting with its log message. If you do not need to
|
||||
edit the message further, you can give `-C` option instead.
|
||||
+
|
||||
See also the `--amend` option to linkgit:git-commit[1].
|
||||
|
||||
|
|
@ -155,9 +155,9 @@ $ git checkout topic/wip <3>
|
|||
------------
|
||||
+
|
||||
<1> You have made some commits, but realize they were premature
|
||||
to be in the `master` branch. You want to continue polishing
|
||||
them in a topic branch, so create `topic/wip` branch off of the
|
||||
current `HEAD`.
|
||||
to be in the `master` branch. You want to continue polishing
|
||||
them in a topic branch, so create `topic/wip` branch off of the
|
||||
current `HEAD`.
|
||||
<2> Rewind the master branch to get rid of those three commits.
|
||||
<3> Switch to `topic/wip` branch and keep working.
|
||||
|
||||
|
|
@ -169,10 +169,10 @@ $ git reset --hard HEAD~3 <1>
|
|||
------------
|
||||
+
|
||||
<1> The last three commits (`HEAD`, `HEAD^`, and `HEAD~2`) were bad
|
||||
and you do not want to ever see them again. Do *not* do this if
|
||||
you have already given these commits to somebody else. (See the
|
||||
"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
|
||||
the implications of doing so.)
|
||||
and you do not want to ever see them again. Do *not* do this if
|
||||
you have already given these commits to somebody else. (See the
|
||||
"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1]
|
||||
for the implications of doing so.)
|
||||
|
||||
Undo a merge or pull::
|
||||
+
|
||||
|
|
@ -189,18 +189,18 @@ $ git reset --hard ORIG_HEAD <4>
|
|||
------------
|
||||
+
|
||||
<1> Try to update from the upstream resulted in a lot of
|
||||
conflicts; you were not ready to spend a lot of time merging
|
||||
right now, so you decide to do that later.
|
||||
conflicts; you were not ready to spend a lot of time merging
|
||||
right now, so you decide to do that later.
|
||||
<2> "pull" has not made merge commit, so `git reset --hard`
|
||||
which is a synonym for `git reset --hard HEAD` clears the mess
|
||||
from the index file and the working tree.
|
||||
which is a synonym for `git reset --hard HEAD` clears the mess
|
||||
from the index file and the working tree.
|
||||
<3> Merge a topic branch into the current branch, which resulted
|
||||
in a fast-forward.
|
||||
in a fast-forward.
|
||||
<4> But you decided that the topic branch is not ready for public
|
||||
consumption yet. "pull" or "merge" always leaves the original
|
||||
tip of the current branch in `ORIG_HEAD`, so resetting hard to it
|
||||
brings your index file and the working tree back to that state,
|
||||
and resets the tip of the branch to that commit.
|
||||
consumption yet. "pull" or "merge" always leaves the original
|
||||
tip of the current branch in `ORIG_HEAD`, so resetting hard to it
|
||||
brings your index file and the working tree back to that state,
|
||||
and resets the tip of the branch to that commit.
|
||||
|
||||
Undo a merge or pull inside a dirty working tree::
|
||||
+
|
||||
|
|
@ -214,14 +214,14 @@ $ git reset --merge ORIG_HEAD <2>
|
|||
------------
|
||||
+
|
||||
<1> Even if you may have local modifications in your
|
||||
working tree, you can safely say `git pull` when you know
|
||||
that the change in the other branch does not overlap with
|
||||
them.
|
||||
working tree, you can safely say `git pull` when you know
|
||||
that the change in the other branch does not overlap with
|
||||
them.
|
||||
<2> After inspecting the result of the merge, you may find
|
||||
that the change in the other branch is unsatisfactory. Running
|
||||
`git reset --hard ORIG_HEAD` will let you go back to where you
|
||||
were, but it will discard your local changes, which you do not
|
||||
want. `git reset --merge` keeps your local changes.
|
||||
that the change in the other branch is unsatisfactory. Running
|
||||
`git reset --hard ORIG_HEAD` will let you go back to where you
|
||||
were, but it will discard your local changes, which you do not
|
||||
want. `git reset --merge` keeps your local changes.
|
||||
|
||||
|
||||
Interrupted workflow::
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ This is what linkgit:git-format-patch[1] generates. Most headers and MIME
|
|||
formatting are ignored.
|
||||
|
||||
2. The original format used by Greg Kroah-Hartman's 'send_lots_of_email.pl'
|
||||
script
|
||||
script
|
||||
+
|
||||
This format expects the first line of the file to contain the "Cc:" value
|
||||
and the "Subject:" of the message as the second line.
|
||||
|
|
|
|||
|
|
@ -237,16 +237,16 @@ your repository directly), then others will have already seen
|
|||
the old tag. In that case you can do one of two things:
|
||||
|
||||
. The sane thing.
|
||||
Just admit you screwed up, and use a different name. Others have
|
||||
already seen one tag-name, and if you keep the same name, you
|
||||
may be in the situation that two people both have "version X",
|
||||
but they actually have 'different' "X"'s. So just call it "X.1"
|
||||
and be done with it.
|
||||
Just admit you screwed up, and use a different name. Others have
|
||||
already seen one tag-name, and if you keep the same name, you
|
||||
may be in the situation that two people both have "version X",
|
||||
but they actually have 'different' "X"'s. So just call it "X.1"
|
||||
and be done with it.
|
||||
|
||||
. The insane thing.
|
||||
You really want to call the new version "X" too, 'even though'
|
||||
others have already seen the old one. So just use 'git tag -f'
|
||||
again, as if you hadn't already published the old one.
|
||||
You really want to call the new version "X" too, 'even though'
|
||||
others have already seen the old one. So just use 'git tag -f'
|
||||
again, as if you hadn't already published the old one.
|
||||
|
||||
However, Git does *not* (and it should not) change tags behind
|
||||
users back. So if somebody already got the old tag, doing a
|
||||
|
|
|
|||
|
|
@ -22,7 +22,6 @@ The UI for the protocol is on the 'git fetch-pack' side, and the
|
|||
program pair is meant to be used to pull updates from a remote
|
||||
repository. For push operations, see 'git send-pack'.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
|
|
|
|||
|
|
@ -270,13 +270,13 @@ depending on a few rules:
|
|||
+
|
||||
--
|
||||
1. If the starting point is specified as `ref@{Nth}`, show the index
|
||||
format.
|
||||
format.
|
||||
+
|
||||
2. If the starting point was specified as `ref@{now}`, show the
|
||||
timestamp format.
|
||||
timestamp format.
|
||||
+
|
||||
3. If neither was used, but `--date` was given on the command line, show
|
||||
the timestamp in the format requested by `--date`.
|
||||
the timestamp in the format requested by `--date`.
|
||||
+
|
||||
4. Otherwise, show the index format.
|
||||
--
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче