.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-CHECKOUT" "1" "02/13/2007" "" ""
+.TH "GIT\-CHECKOUT" "1" "02/18/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
\-m
If you have local modifications to one or more files that are different between the current branch and the branch to which you are switching, the command refuses to switch branches in order to preserve your modifications in context. However, with this option, a three\-way merge between the current branch, your working tree contents, and the new branch is done, and you will be on the new branch.
-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.
+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 (or git rm if the merge should result in deletion of the path).
.TP
<new_branch>
Name for the new branch.
ERROR: Merge conflict in frotz
fatal: merge program failed
.fi
-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:
+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 add as usual:
.sp
.nf
$ edit frotz
-$ git update\-index frotz
+$ git add frotz
.fi
.SH "AUTHOR"
Written by Linus Torvalds <torvalds@osdl.org>
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-MERGE" "1" "02/13/2007" "" ""
+.TH "GIT\-MERGE" "1" "02/18/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
Decide not to merge. The only clean\-up you need are to reset the index file to the HEAD commit to reverse 2. and to clean up working tree changes made by 2. and 3.; git\-reset can be used for this.
.TP
\(bu
-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 them, to make the index file contain what the merge result should be, and run git\-commit to commit the result.
+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 or git\-rm them, to make the index file contain what the merge result should be, and run git\-commit to commit the result.
.SH "SEE ALSO"
\fBgit\-fmt\-merge\-msg\fR(1), \fBgit\-pull\fR(1)
.SH "AUTHOR"
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-NAME\-REV" "1" "10/03/2006" "" ""
+.TH "GIT\-NAME\-REV" "1" "02/18/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.SH "NAME"
git\-name\-rev \- Find symbolic names for given revs
.SH "SYNOPSIS"
-\fIgit\-name\-rev\fR [\-\-tags] ( \-\-all | \-\-stdin | <committish>\&... )
-.sp
+\fIgit\-name\-rev\fR [\-\-tags] [\-\-refs=<pattern>] ( \-\-all | \-\-stdin | <committish>\&... )
.SH "DESCRIPTION"
Finds symbolic names suitable for human digestion for revisions given in any format parsable by git\-rev\-parse.
-.sp
.SH "OPTIONS"
.TP
\-\-tags
Do not use branch names, but only tags to name the commits
.TP
+\-\-refs=<pattern>
+Only use refs whose names match a given shell pattern.
+.TP
\-\-all
List all commits reachable from all refs
.TP
Read from stdin, append "(<rev_name>)" to all sha1's of nameable commits, and pass to stdout
.SH "EXAMPLE"
Given a commit, find out where it is relative to the local refs. Say somebody wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a. Of course, you look into the commit, but that only tells you what happened, but not the context.
-.sp
+
Enter git\-name\-rev:
.sp
-.sp
.nf
% git name\-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99^0~940
.fi
Now you are wiser, because you know that it happened 940 revisions before v0.99.
-.sp
+
Another nice thing you can do is:
.sp
-.sp
.nf
% git log | git name\-rev \-\-stdin
.fi
.SH "AUTHOR"
Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
-.sp
.SH "DOCUMENTATION"
Documentation by Johannes Schindelin.
-.sp
.SH "GIT"
Part of the \fBgit\fR(7) suite
-.sp
+
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-REBASE" "1" "02/12/2007" "" ""
+.TH "GIT\-REBASE" "1" "02/18/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
\fIgit\-rebase\fR \-\-continue | \-\-skip | \-\-abort
.SH "DESCRIPTION"
-git\-rebase replaces <branch> with a new branch of the same name. When the \-\-onto option is provided the new branch starts out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>. It then attempts to create a new commit for each commit from the original <branch> that does not exist in the <upstream> branch.
+If <branch> is specified, git\-rebase will perform an automatic git checkout <branch> before doing anything else. Otherwise it remains on the current branch.
-It is possible that a merge failure will prevent this process from being completely automatic. You will have to resolve any such merge failure and run git rebase \-\-continue. Another option is to bypass the commit that caused the merge failure with git rebase \-\-skip. To restore the original <branch> and remove the .dotest working files, use the command git rebase \-\-abort instead.
+All changes made by commits in the current branch but that are not in <upstream> are saved to a temporary area. This is the same set of commits that would be shown by git log <upstream>..HEAD.
+
+The current branch is reset to <upstream>, or <newbase> if the \-\-onto option was supplied. This has the exact same effect as git reset \-\-hard <upstream> (or <newbase>).
-Note that if <branch> is not specified on the command line, the currently checked out branch is used.
+The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order.
+
+It is possible that a merge failure will prevent this process from being completely automatic. You will have to resolve any such merge failure and run git rebase \-\-continue. Another option is to bypass the commit that caused the merge failure with git rebase \-\-skip. To restore the original <branch> and remove the .dotest working files, use the command git rebase \-\-abort instead.
Assume the following history exists and the current branch is "topic":
.sp
In case of conflict, git\-rebase will stop at the first problematic commit and leave conflict markers in the tree. You can use git diff to locate the markers (<<<<<<) and make edits to resolve the conflict. For each file you edit, you need to tell git that the conflict has been resolved, typically this would be done with
.sp
.nf
-git update\-index <filename>
+git add <filename>
.fi
After resolving the conflict manually and updating the index with the desired resolution, you can continue the rebasing process with
.sp
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-RERERE" "1" "01/19/2007" "" ""
+.TH "GIT\-RERERE" "1" "02/18/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
Running git\-rerere command immediately after a conflicted automerge records the conflicted working tree files, with the usual conflict markers <<<<<<<, =======, and >>>>>>> in them. Later, after you are done resolving the conflicts, running git\-rerere again records the resolved state of these files. Suppose you did this when you created the test merge of master into the topic branch.
-Next time, running git\-rerere after seeing a conflicted automerge, if the conflict is the same as the earlier one recorded, it is noticed and a three\-way merge between the earlier conflicted automerge, the earlier manual resolution, and the current conflicted automerge is performed by the command. 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.
+Next time, running git\-rerere after seeing a conflicted automerge, if the conflict is the same as the earlier one recorded, it is noticed and a three\-way merge between the earlier conflicted automerge, the earlier manual resolution, and the current conflicted automerge is performed by the command. 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 add when you are satisfied.
As a convenience measure, git\-merge automatically invokes git\-rerere when it exits with a failed automerge, which records it if it is a new conflict, or reuses the earlier hand resolve when it is not. git\-commit also invokes git\-rerere when recording a merge result. What this means is that you do not have to do anything special yourself (Note: you still have to create $GIT_DIR/rr\-cache directory to enable this command).
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-RESET" "1" "01/15/2007" "" ""
+.TH "GIT\-RESET" "1" "02/18/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
\fB3. \fRSwitch to "topic/wip" branch and keep working.
.br
.TP
-Undo update\-index
+Undo add
.sp
.nf
$ edit \fB(1)\fR
-$ git\-update\-index frotz.c filfre.c
+$ git add frotz.c filfre.c
$ mailx \fB(2)\fR
$ git reset \fB(3)\fR
$ git pull git://info.example.com/ nitfol \fB(4)\fR
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-RUNSTATUS" "1" "11/18/2006" "" ""
+.TH "GIT\-RUNSTATUS" "1" "02/18/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
git\-runstatus \- A helper for git\-status and git\-commit
.SH "SYNOPSIS"
\fIgit\-runstatus\fR [\-\-color|\-\-nocolor] [\-\-amend] [\-\-verbose] [\-\-untracked]
-.sp
.SH "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 \fIgit\-update\-index\fR before running \fIgit commit\fR, and the latter paths are what you _would_ commit by running \fIgit commit\fR.
-.sp
+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 \fIgit add\fR (or \fIgit rm\fR if you are deleting) before running \fIgit commit\fR, and the latter paths are what you _would_ commit by running \fIgit commit\fR.
+
If there is no path that is different between the index file and the current HEAD commit, the command exits with non\-zero status.
-.sp
+
Note that this is _not_ the user level command you would want to run from the command line. Use \fIgit\-status\fR instead.
-.sp
.SH "OPTIONS"
.TP
\-\-color
Turn off coloring.
.TP
\-\-amend
-Show status based on HEAD^1, not HEAD, i.e. show what
-\fIgit\-commit \-\-amend\fR
-would do.
+Show status based on HEAD^1, not HEAD, i.e. show what \fIgit\-commit \-\-amend\fR would do.
.TP
\-\-verbose
Show unified diff of all file changes.
Show files in untracked directories, too. Without this option only its name and a trailing slash are displayed for each untracked directory.
.SH "OUTPUT"
The output from this command is designed to be used as a commit template comments, and all the output lines are prefixed with \fI#\fR.
-.sp
.SH "AUTHOR"
Originally written by Linus Torvalds <torvalds@osdl.org> as part of git\-commit, and later rewritten in C by Jeff King.
-.sp
.SH "DOCUMENTATION"
Documentation by David Greaves, Junio C Hamano and the git\-list <git@vger.kernel.org>.
-.sp
.SH "GIT"
Part of the \fBgit\fR(7) suite
-.sp
+
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-STATUS" "1" "01/19/2007" "" ""
+.TH "GIT\-STATUS" "1" "02/18/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.SH "SYNOPSIS"
\fIgit\-status\fR <options>\&...
.SH "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 \fIgit\-update\-index\fR before running \fIgit commit\fR, and the latter paths are what you _would_ commit by running \fIgit commit\fR.
+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 \fIgit add\fR before running \fIgit commit\fR, and the latter paths are what you _would_ commit by running \fIgit commit\fR.
If there is no path that is different between the index file and the current HEAD commit, the command exits with non\-zero status.
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT" "7" "02/14/2007" "" ""
+.TH "GIT" "7" "02/18/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
In particular, since the blob is entirely defined by its data, if two files in a directory tree (or in multiple different versions of the repository) have the same contents, they will share the same blob object. The object is totally independent of its location in the 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 \fBgit\-update\-index\fR(1) is run, and its data can be accessed by \fBgit\-cat\-file\fR(1).
+A blob is typically created when \fBgit\-update\-index\fR(1) (or \fBgit\-add\fR(1)) is run, and its data can be accessed by \fBgit\-cat\-file\fR(1).
.SS "Tree Object"
The next hierarchical object type is the "tree" object. A tree object is a list of mode/name/blob data, sorted by name. Alternatively, the mode data may specify a directory mode, in which case instead of naming a blob, that name is associated with another TREE object.
projects / git.git / commitdiff