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

manual: Fix or remove em dashes.

Browse Source 
em dashes were used inconsistently in the manual.
This changes them to the way they are used in US English.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This commit is contained in:
Ralf Wildenhues 2007-10-09 23:05:30 +02:00 committed by Shawn O. Pearce
parent 11f2441f05
commit 2ef8ac1b2a
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
Documentation/user-manual.txt
View File

@ -2756,7 +2756,7 @@ There are four different types of objects: "blob", "tree", "commit", and
"blob" objects into a directory structure. In addition, a tree object "blob" objects into a directory structure. In addition, a tree object
can refer to other tree objects, thus creating a directory hierarchy. can refer to other tree objects, thus creating a directory hierarchy.
- A <<def_commit_object,"commit" object>> ties such directory hierarchies - A <<def_commit_object,"commit" object>> ties such directory hierarchies
together into a <<def_DAG,directed acyclic graph>> of revisions - each together into a <<def_DAG,directed acyclic graph>> of revisions--each
commit contains the object name of exactly one tree designating the commit contains the object name of exactly one tree designating the
directory hierarchy at the time of the commit. In addition, a commit directory hierarchy at the time of the commit. In addition, a commit
refers to "parent" commit objects that describe the history of how we refers to "parent" commit objects that describe the history of how we
@ -3029,7 +3029,7 @@ There are also other situations that cause dangling objects. For
example, a "dangling blob" may arise because you did a "git add" of a example, a "dangling blob" may arise because you did a "git add" of a
file, but then, before you actually committed it and made it part of the file, but then, before you actually committed it and made it part of the
bigger picture, you changed something else in that file and committed bigger picture, you changed something else in that file and committed
that *updated* thing - the old state that you added originally ends up that *updated* thing--the old state that you added originally ends up
not being pointed to by any commit or tree, so it's now a dangling blob not being pointed to by any commit or tree, so it's now a dangling blob
object. object.
@ -3044,7 +3044,7 @@ up pointing to them, so they end up "dangling" in your repository.
Generally, dangling objects aren't anything to worry about. They can Generally, dangling objects aren't anything to worry about. They can
even be very useful: if you screw something up, the dangling objects can even be very useful: if you screw something up, the dangling objects can
be how you recover your old tree (say, you did a rebase, and realized be how you recover your old tree (say, you did a rebase, and realized
that you really didn't want to - you can look at what dangling objects that you really didn't want to--you can look at what dangling objects
you have, and decide to reset your head to some old dangling state). you have, and decide to reset your head to some old dangling state).
For commits, you can just use: For commits, you can just use:
@ -3088,10 +3088,10 @@ $ git prune
------------------------------------------------ ------------------------------------------------
and they'll be gone. But you should only run "git prune" on a quiescent and they'll be gone. But you should only run "git prune" on a quiescent
repository - it's kind of like doing a filesystem fsck recovery: you repository--it's kind of like doing a filesystem fsck recovery: you
don't want to do that while the filesystem is mounted. don't want to do that while the filesystem is mounted.
(The same is true of "git-fsck" itself, btw - but since (The same is true of "git-fsck" itself, btw, but since
git-fsck never actually *changes* the repository, it just reports git-fsck never actually *changes* the repository, it just reports
on what it found, git-fsck itself is never "dangerous" to run. on what it found, git-fsck itself is never "dangerous" to run.
Running it while somebody is actually changing the repository can cause Running it while somebody is actually changing the repository can cause
@ -3482,7 +3482,7 @@ You write your current index file to a "tree" object with the program
$ git write-tree $ git write-tree
------------------------------------------------- -------------------------------------------------
that doesn't come with any options - it will just write out the that doesn't come with any options--it will just write out the
current index into the set of tree objects that describe that state, current index into the set of tree objects that describe that state,
and it will return the name of the resulting top-level tree. You can and it will return the name of the resulting top-level tree. You can
use that tree to re-generate the index at any time by going in the use that tree to re-generate the index at any time by going in the
@ -3493,7 +3493,7 @@ object database -> index
~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
You read a "tree" file from the object database, and use that to You read a "tree" file from the object database, and use that to
populate (and overwrite - don't do this if your index contains any populate (and overwrite--don't do this if your index contains any
unsaved state that you might want to restore later!) your current unsaved state that you might want to restore later!) your current
index. Normal operation is just index. Normal operation is just
@ -3541,7 +3541,7 @@ Tying it all together
To commit a tree you have instantiated with "git-write-tree", you'd To commit a tree you have instantiated with "git-write-tree", you'd
create a "commit" object that refers to that tree and the history create a "commit" object that refers to that tree and the history
behind it - most notably the "parent" commits that preceded it in behind it--most notably the "parent" commits that preceded it in
history. history.
Normally a "commit" has one parent: the previous state of the tree Normally a "commit" has one parent: the previous state of the tree
@ -3684,7 +3684,7 @@ Once you know the three trees you are going to merge (the one "original"
tree, aka the common tree, and the two "result" trees, aka the branches tree, aka the common tree, and the two "result" trees, aka the branches
you want to merge), you do a "merge" read into the index. This will you want to merge), you do a "merge" read into the index. This will
complain if it has to throw away your old index contents, so you should complain if it has to throw away your old index contents, so you should
make sure that you've committed those - in fact you would normally make sure that you've committed those--in fact you would normally
always do a merge against your last commit (which should thus match what always do a merge against your last commit (which should thus match what
you have in your current index anyway). you have in your current index anyway).
@ -3956,7 +3956,7 @@ Two things are interesting here:
- `get_sha1()` returns 0 on _success_. This might surprise some new - `get_sha1()` returns 0 on _success_. This might surprise some new
Git hackers, but there is a long tradition in UNIX to return different Git hackers, but there is a long tradition in UNIX to return different
negative numbers in case of different errors -- and 0 on success. negative numbers in case of different errors--and 0 on success.
- the variable `sha1` in the function signature of `get_sha1()` is `unsigned - the variable `sha1` in the function signature of `get_sha1()` is `unsigned
char \*`, but is actually expected to be a pointer to `unsigned char \*`, but is actually expected to be a pointer to `unsigned