For the complete list of paths which git checks for references, and
the order it uses to decide which to choose when there are multiple
references with the same shorthand name, see the "SPECIFYING
-REVISIONS" section of linkgit:gitrevisions[1].
+REVISIONS" section of linkgit:gitrevisions[7].
[[Updating-a-repository-With-git-fetch]]
Updating a repository with git fetch
- HEAD: refers to the head of the current branch
There are many more; see the "SPECIFYING REVISIONS" section of the
-linkgit:gitrevisions[1] man page for the complete list of ways to
+linkgit:gitrevisions[7] man page for the complete list of ways to
name revisions. Some examples:
-------------------------------------------------
$ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
-------------------------------------------------
-(See linkgit:gitrevisions[1] for explanations of commit-selecting
+(See linkgit:gitrevisions[7] for explanations of commit-selecting
syntax such as `--not`.)
[[making-a-release]]
and then he just cut-and-pastes the output commands after verifying that
they look OK.
-[[Finding-comments-With-given-Content]]
+[[Finding-commits-With-given-Content]]
Finding commits referencing a file with given content
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The reflogs are kept by default for 30 days, after which they may be
pruned. See linkgit:git-reflog[1] and linkgit:git-gc[1] to learn
how to control this pruning, and see the "SPECIFYING REVISIONS"
-section of linkgit:gitrevisions[1] for details.
+section of linkgit:gitrevisions[7] for details.
Note that the reflog history is very different from normal git history.
While normal history is shared by every repository that works on the
sequence of patches on top of "origin":
................................................
- o--o--o <-- origin
+ o--o--O <-- origin
\
- o--o--o <-- mywork
+ a--b--c <-- mywork
................................................
Some more interesting work has been done in the upstream project, and