Convert update-index references in docs to add.
PATCH 1/1 Convert update-index references in docs to add.
Since git add is the approved porcelain for an end-user to invoke when they want to manipulate the index, porcelain documentation should steer the user to this command rather than the pure plumbing update-index.
---
Maybe this isn't the best change to make. I dunno. I think it is cleaner to keep the user looking at add instead of update-index, but what do I know. :-)
Documentation/core-intro.txt | 3 ++- Documentation/git-checkout.txt | 6 +++--- Documentation/git-merge.txt | 2 +- Documentation/git-rebase.txt | 2 +- Documentation/git-rerere.txt | 3 +-- Documentation/git-reset.txt | 4 ++-- Documentation/git-runstatus.txt | 2 +- Documentation/git-status.txt | 2 +- Documentation/tutorial-2.txt | 4 ++-- 9 files changed, 14 insertions(+), 14 deletions(-)
Documentation/core-intro.txt +2 -1
@@ -106,7 +106,8 @@ directory tree, and renaming a file does not change the object that file is associated with in any way. A blob is typically created when gitlink:git-update-index[1] -is run, and its data can be accessed by gitlink:git-cat-file[1]. +(or gitlink:git-add[1]) is run, and its data can be accessed by +gitlink:git-cat-file[1]. Tree Object ~~~~~~~~~~~
Documentation/git-checkout.txt +3 -3
@@ -61,7 +61,7 @@ OPTIONS + When a merge conflict happens, the index entries for conflicting paths are left unmerged, and you need to resolve the conflicts -and mark the resolved paths with `git update-index`. +and mark the resolved paths with `git add`. <new_branch>:: Name for the new branch.
@@ -179,11 +179,11 @@ fatal: merge program failed At this point, `git diff` shows the changes cleanly merged as in the previous example, as well as the changes in the conflicted files. Edit and resolve the conflict and mark it resolved with -`git update-index` as usual: +`git add` as usual: + ------------ $ edit frotz -$ git update-index frotz +$ git add frotz ------------
Documentation/git-merge.txt +1 -1
@@ -136,7 +136,7 @@ After seeing a conflict, you can do two things: * Resolve the conflicts. `git-diff` would report only the conflicting paths because of the above 2. and 3.. Edit the - working tree files into a desirable shape, `git-update-index` + working tree files into a desirable shape, `git-add` them, to make the index file contain what the merge result should be, and run `git-commit` to commit the result.
Documentation/git-rebase.txt +1 -1
@@ -142,7 +142,7 @@ file you edit, you need to tell git that the conflict has been resolved, typically this would be done with - git update-index <filename> + git add <filename> After resolving the conflict manually and updating the index with the
Documentation/git-rerere.txt +1 -2
@@ -163,8 +163,7 @@ If this three-way merge resolves cleanly, the result is written out to your working tree file, so you would not have to manually resolve it. Note that `git-rerere` leaves the index file alone, so you still need to do the final sanity checks with `git diff` -(or `git diff -c`) and `git update-index` when you are -satisfied. +(or `git diff -c`) and `git add` when you are satisfied. As a convenience measure, `git-merge` automatically invokes `git-rerere` when it exits with a failed automerge, which
Documentation/git-reset.txt +2 -2
@@ -94,11 +94,11 @@ current HEAD. <2> Rewind the master branch to get rid of those three commits. <3> Switch to "topic/wip" branch and keep working. -Undo update-index:: +Undo add:: + ------------ $ edit <1> -$ git-update-index frotz.c filfre.c +$ git add frotz.c filfre.c $ mailx <2> $ git reset <3> $ git pull git://info.example.com/ nitfol <4>
Documentation/git-runstatus.txt +1 -1
@@ -16,7 +16,7 @@ DESCRIPTION Examines paths in the working tree that has changes unrecorded to the index file, and changes between the index file and the current HEAD commit. The former paths are what you _could_ -commit by running 'git-update-index' before running 'git +commit by running 'git add' before running 'git commit', and the latter paths are what you _would_ commit by running 'git commit'.
Documentation/git-status.txt +1 -1
@@ -15,7 +15,7 @@ DESCRIPTION Examines paths in the working tree that has changes unrecorded to the index file, and changes between the index file and the current HEAD commit. The former paths are what you _could_ -commit by running 'git-update-index' before running 'git +commit by running 'git add' before running 'git commit', and the latter paths are what you _would_ commit by running 'git commit'.
Documentation/tutorial-2.txt +2 -2
@@ -227,7 +227,7 @@ $ git diff @@ -1 +1,2 @@ hello world! +hello world, again -$ git update-index file.txt +$ git add file.txt $ git diff ------------------------------------------------
@@ -260,7 +260,7 @@ hello world! hello world, again ------------------------------------------------ -So what our "git update-index" did was store a new blob and then put +So what our "git add" did was store a new blob and then put a reference to it in the index file. If we modify the file again, we'll see that the new modifications are reflected in the "git-diff" output:
Signature · 1 line
1.5.0.552.ge1b1c
Quoted 11 lines · Shawn O. Pearce
Since
git addis the approved porcelain for an end-user to invoke when they want to manipulate the index, porcelain documentation should steer the user to this command rather than the pure plumbing update-index.Signed-off-by Shawn O. Pearce <[email protected]>---
Maybe this isn't the best change to make. I dunno. I think it is cleaner to keep the user looking at add instead of update-index, but what do I know. :-)
I think I agree with most of your changes, except in a few places we should suggest 'git rm' to resolve conflict as deletion of paths. On top of your patch, something like the attached.
One thing I suspect is that currently we refuse to 'git rm' if the index does not match working tree and HEAD, but it might make sense to skip that check when the path is unmerged in the index.
Documentation/git-checkout.txt +2 -1
@@ -61,7 +61,8 @@ OPTIONS + When a merge conflict happens, the index entries for conflicting paths are left unmerged, and you need to resolve the conflicts -and mark the resolved paths with `git add`. +and mark the resolved paths with `git add` (or `git rm` if the merge +should result in deletion of the path). <new_branch>:: Name for the new branch.
Documentation/git-merge.txt +1 -1
@@ -136,7 +136,7 @@ After seeing a conflict, you can do two things: * Resolve the conflicts. `git-diff` would report only the conflicting paths because of the above 2. and 3.. Edit the - working tree files into a desirable shape, `git-add` + working tree files into a desirable shape, `git-add` or `git-rm` them, to make the index file contain what the merge result should be, and run `git-commit` to commit the result.
Documentation/git-runstatus.txt +1 -1
@@ -16,7 +16,7 @@ DESCRIPTION Examines paths in the working tree that has changes unrecorded to the index file, and changes between the index file and the current HEAD commit. The former paths are what you _could_ -commit by running 'git add' before running 'git +commit by running 'git add' (or 'git rm' if you are deleting) before running 'git commit', and the latter paths are what you _would_ commit by running 'git commit'.