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:git-rev-parse[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:git-rev-parse[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:git-rev-parse[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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and if you don't, then linkgit:git-stash[1] can take these changes
away while you're doing the merge, and reapply them afterwards.
-If the changes are independant enough, Git will automatically complete
+If the changes are independent enough, Git will automatically complete
the merge and commit the result (or reuse an existing commit in case
of <<fast-forwards,fast-forward>>, see below). On the other hand,
if there are conflicts--for example, if the same file is
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:git-rev-parse[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
Now to apply some patches from the community. Think of a short
snappy name for a branch to hold this patch (or related group of
-patches), and create a new branch from the current tip of Linus's
-branch:
+patches), and create a new branch from a recent stable tag of
+Linus's branch. Picking a stable base for your branch will:
+1) help you: by avoiding inclusion of unrelated and perhaps lightly
+tested changes
+2) help future bug hunters that use "git bisect" to find problems
-------------------------------------------------
-$ git checkout -b speed-up-spinlocks origin
+$ git checkout -b speed-up-spinlocks v2.6.35
-------------------------------------------------
Now you apply the patch(es), run some tests, and commit the change(s). If
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
Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a'
-------------------------------------------------
+In older git versions it could be easily forgotten to commit new or modified
+files in a submodule, which silently leads to similar problems as not pushing
+the submodule changes. Starting with git 1.7.0 both "git status" and "git diff"
+in the superproject show submodules as modified when they contain new or
+modified files to protect against accidentally committing such a state. "git
+diff" will also add a "-dirty" to the work tree side when generating patch
+output or used with the --submodule option:
+
+-------------------------------------------------
+$ git diff
+diff --git a/sub b/sub
+--- a/sub
++++ b/sub
+@@ -1 +1 @@
+-Subproject commit 3f356705649b5d566d97ff843cf193359229a453
++Subproject commit 3f356705649b5d566d97ff843cf193359229a453-dirty
+$ git diff --submodule
+Submodule sub 3f35670..3f35670-dirty:
+-------------------------------------------------
+
You also should not rewind branches in a submodule beyond commits that were
ever recorded in any superproject.
state at the time of the commit, and a list of parents:
-------------------------------------------------
-$ git commit-tree <tree> -p <parent> [-p <parent2> ..]
+$ git commit-tree <tree> -p <parent> [(-p <parent2>)...]
-------------------------------------------------
and then giving the reason for the commit on stdin (either through
negative numbers in case of different errors--and 0 on success.
- the variable `sha1` in the function signature of `get_sha1()` is `unsigned
- char \*`, but is actually expected to be a pointer to `unsigned
+ char {asterisk}`, but is actually expected to be a pointer to `unsigned
char[20]`. This variable will contain the 160-bit SHA-1 of the given
- commit. Note that whenever a SHA-1 is passed as `unsigned char \*`, it
+ commit. Note that whenever a SHA-1 is passed as `unsigned char {asterisk}`, it
is the binary representation, as opposed to the ASCII representation in
hex characters, which is passed as `char *`.