From: Junio C Hamano Date: Fri, 17 Aug 2007 07:48:07 +0000 (+0000) Subject: Autogenerated manpages for v1.5.3-rc5-15-ga9ab2 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=90097353ea617fdb5572b91891c5f87981594829;p=git.git Autogenerated manpages for v1.5.3-rc5-15-ga9ab2 --- diff --git a/man1/git-add.1 b/man1/git-add.1 index 9596b1983..e0d0d67c2 100644 --- a/man1/git-add.1 +++ b/man1/git-add.1 @@ -2,7 +2,7 @@ .\" 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\-ADD" "1" "08/14/2007" "Git 1.5.3.rc4.91.g9fa34" "Git Manual" +.TH "GIT\-ADD" "1" "08/17/2007" "Git 1.5.3.rc5.15.ga9ab2" "Git Manual" .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) @@ -20,7 +20,7 @@ This command can be performed multiple times before a commit. It only adds the c The \fIgit status\fR command can be used to obtain a summary of which files have changes that are staged for the next commit. -The \fIadd\fR command can be used to add ignored files with \-f (force) option, but they have to be explicitly and exactly specified from the command line. File globbing and recursive behaviour do not add ignored files. +The \fIgit add\fR command will not add ignored files by default. If any ignored files were explicitly specified on the command line, \fIgit add\fR will fail with a list of ignored files. Ignored files reached by directory recursion or filename globbing will be silently ignored. The \fIadd\fR command can be used to add ignored files with the \-f (force) option. Please see \fBgit\-commit\fR(1) for alternative ways to add content to a commit. .SH "OPTIONS" diff --git a/man1/git-rebase.1 b/man1/git-rebase.1 index 9aafc54ea..273ae8862 100644 --- a/man1/git-rebase.1 +++ b/man1/git-rebase.1 @@ -2,7 +2,7 @@ .\" 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" "07/19/2007" "Git 1.5.3.rc0" "Git Manual" +.TH "GIT\-REBASE" "1" "08/17/2007" "Git 1.5.3.rc5.15.ga9ab2" "Git Manual" .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) @@ -30,9 +30,12 @@ It is possible that a merge failure will prevent this process from being complet Assume the following history exists and the current branch is "topic": .sp .nf +.ft C A\-\-\-B\-\-\-C topic / D\-\-\-E\-\-\-F\-\-\-G master +.ft + .fi From this point, the result of either of the following commands: .sp @@ -43,9 +46,12 @@ git\-rebase master topic would be: .sp .nf +.ft C A'\-\-B'\-\-C' topic / D\-\-\-E\-\-\-F\-\-\-G master +.ft + .fi The latter form is just a short\-hand of git checkout topic followed by git rebase master. @@ -54,20 +60,26 @@ Here is how you would transplant a topic branch based on one branch to another, First let's assume your \fItopic\fR is based on branch \fInext\fR. For example feature developed in \fItopic\fR depends on some functionality which is found in \fInext\fR. .sp .nf +.ft C o\-\-\-o\-\-\-o\-\-\-o\-\-\-o master \\ o\-\-\-o\-\-\-o\-\-\-o\-\-\-o next \\ o\-\-\-o\-\-\-o topic +.ft + .fi We would want to make \fItopic\fR forked from branch \fImaster\fR, for example because the functionality \fItopic\fR branch depend on got merged into more stable \fImaster\fR branch, like this: .sp .nf +.ft C o\-\-\-o\-\-\-o\-\-\-o\-\-\-o master | \\ | o'\-\-o'\-\-o' topic \\ o\-\-\-o\-\-\-o\-\-\-o\-\-\-o next +.ft + .fi We can get this using the following command: .sp @@ -77,11 +89,14 @@ git\-rebase \-\-onto master next topic Another example of \-\-onto option is to rebase part of a branch. If we have the following situation: .sp .nf +.ft C H\-\-\-I\-\-\-J topicB / E\-\-\-F\-\-\-G topicA / A\-\-\-B\-\-\-C\-\-\-D master +.ft + .fi then the command .sp @@ -91,28 +106,37 @@ git\-rebase \-\-onto master topicA topicB would result in: .sp .nf +.ft C H'\-\-I'\-\-J' topicB / | E\-\-\-F\-\-\-G topicA |/ A\-\-\-B\-\-\-C\-\-\-D master +.ft + .fi This is useful when topicB does not depend on topicA. A range of commits could also be removed with rebase. If we have the following situation: .sp .nf +.ft C E\-\-\-F\-\-\-G\-\-\-H\-\-\-I\-\-\-J topicA +.ft + .fi then the command .sp .nf -git\-rebase \-\-onto topicA~5 topicA~2 topicA +git\-rebase \-\-onto topicA~5 topicA~3 topicA .fi would result in the removal of commits F and G: .sp .nf +.ft C E\-\-\-H'\-\-\-I'\-\-\-J' topicA +.ft + .fi This is useful if F and G were flawed in some way, or should not be part of topicA. Note that the argument to \-\-onto and the parameter can be any valid commit\-ish. @@ -240,9 +264,12 @@ git rebase \-i An editor will be fired up with all the commits in your current branch (ignoring merge commits), which come after the given commit. You can reorder the commits in this list to your heart's content, and you can remove them. The list looks more or less like this: .sp .nf +.ft C pick deadbee The oneline of this commit pick fa1afe1 The oneline of the next commit ... +.ft + .fi The oneline descriptions are purely for your pleasure; git\-rebase will not look at them but at the commit names ("deadbee" and "fa1afe1" in this example), so do not delete or edit the names. @@ -255,23 +282,32 @@ In both cases, or when a "pick" does not succeed (because of merge errors), the For example, if you want to reorder the last 5 commits, such that what was HEAD~4 becomes the new HEAD. To achieve that, you would call git\-rebase like this: .sp .nf +.ft C $ git rebase \-i HEAD~5 +.ft + .fi And move the first patch to the end of the list. You might want to preserve merges, if you have a history like this: .sp .nf +.ft C X \\ A\-\-\-M\-\-\-B / \-\-\-o\-\-\-O\-\-\-P\-\-\-Q +.ft + .fi Suppose you want to rebase the side branch starting at "A" to "Q". Make sure that the current HEAD is "B", and call .sp .nf +.ft C $ git rebase \-i \-p \-\-onto Q O +.ft + .fi .SH "AUTHORS" Written by Junio C Hamano and Johannes E. Schindelin