Using them as continuation indications for abbreviated SHA-1 values bears the risk that they are mistaken for the dotted range operators. Commands which expect a single commit will fail when given a range of commits. Also, add a note that sometimes, 3dots are just continuation indications. Signed-off-by: Ann T Ropea <bedhanger@xxxxxx> --- Documentation/user-manual.txt | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index b4d88af133e8..bdb44b067399 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -319,7 +319,7 @@ do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name -HEAD is now at 427abfa... Linux v2.6.17 +HEAD is now at 427abfa Linux v2.6.17 ------------------------------------------------ The HEAD then refers to the SHA-1 of the commit instead of to a branch, @@ -508,7 +508,7 @@ Bisecting: 3537 revisions left to test after this If you run `git branch` at this point, you'll see that Git has temporarily moved you in "(no branch)". HEAD is now detached from any -branch and points directly to a commit (with commit id 65934...) that +branch and points directly to a commit (with commit id 65934) that is reachable from "master" but not from v2.6.18. Compile and test it, and see whether it crashes. Assume it does crash. Then: @@ -549,14 +549,14 @@ says "bisect". Choose a safe-looking commit nearby, note its commit id, and check it out with: ------------------------------------------------- -$ git reset --hard fb47ddb2db... +$ git reset --hard fb47ddb2db ------------------------------------------------- then test, run `bisect good` or `bisect bad` as appropriate, and continue. Instead of `git bisect visualize` and then `git reset --hard -fb47ddb2db...`, you might just want to tell Git that you want to skip +fb47ddb2db`, you might just want to tell Git that you want to skip the current commit: ------------------------------------------------- @@ -3426,6 +3426,8 @@ Date: ... :100644 100644 oldsha... 4b9458b... M somedirectory/myfile ------------------------------------------------ +(Note that in the above, the "..." are used as continuation +indications, not as symmetric difference operators!) This tells you that the immediately following version of the file was "newsha", and that the immediately preceding version was "oldsha". @@ -3449,7 +3451,7 @@ and your repository is good again! $ git log --raw --all ------------------------------------------------ -and just looked for the sha of the missing object (4b9458b..) in that +and just looked for the sha of the missing object (4b9458b) in that whole thing. It's up to you--Git does *have* a lot of information, it is just missing one particular blob version. @@ -4114,9 +4116,9 @@ program, e.g. `diff3`, `merge`, or Git's own merge-file, on the blob objects from these three stages yourself, like this: ------------------------------------------------ -$ git cat-file blob 263414f... >hello.c~1 -$ git cat-file blob 06fa6a2... >hello.c~2 -$ git cat-file blob cc44c73... >hello.c~3 +$ git cat-file blob 263414f >hello.c~1 +$ git cat-file blob 06fa6a2 >hello.c~2 +$ git cat-file blob cc44c73 >hello.c~3 $ git merge-file hello.c~2 hello.c~1 hello.c~3 ------------------------------------------------ @@ -4374,7 +4376,7 @@ $ git log --no-merges t/ ------------------------ In the pager (`less`), just search for "bundle", go a few lines back, -and see that it is in commit 18449ab0... Now just copy this object name, +and see that it is in commit 18449ab0. Now just copy this object name, and paste it into the command line ------------------- -- 2.13.6
