.\" 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\-BRANCH" "1" "06/16/2007" "Git 1.5.2.2.236.g952c8" "Git Manual"
+.TH "GIT\-BRANCH" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
With a \fI\-m\fR or \fI\-M\fR option, <oldbranch> will be renamed to <newbranch>. If <oldbranch> had a corresponding reflog, it is renamed to match <newbranch>, and a reflog entry is created to remember the branch renaming. If <newbranch> exists, \-M must be used to force the rename to happen.
-With a \-d or \-D option, <branchname> will be deleted. You may specify more than one branch for deletion. If the branch currently has a ref log then the ref log will also be deleted. Use \-r together with \-d to delete remote\-tracking branches.
+With a \-d or \-D option, <branchname> will be deleted. You may specify more than one branch for deletion. If the branch currently has a reflog then the reflog will also be deleted. Use \-r together with \-d to delete remote\-tracking branches.
.SH "OPTIONS"
.TP
\-d
Delete a branch irrespective of its index status.
.TP
\-l
-Create the branch's ref log. This activates recording of all changes to made the branch ref, enabling use of date
+Create the branch's reflog. This activates recording of all changes made to the branch ref, enabling use of date based sha1 expressions such as "<branchname>@{yesterday}".
.TP
\-f
Force the creation of a new branch even if it means deleting a branch that already exists with the same name.
.\" 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" "06/16/2007" "Git 1.5.2.2.236.g952c8" "Git Manual"
+.TH "GIT\-CHECKOUT" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
When \-b is given and a branch is created off a remote branch, set up configuration so that git\-pull will not retrieve data from the remote branch, ignoring the branch.autosetupmerge configuration variable.
.TP
\-l
-Create the new branch's ref log. This activates recording of all changes to made the branch ref, enabling use of date
+Create the new branch's reflog. This activates recording of all changes made to the branch ref, enabling use of date based sha1 expressions such as "<branchname>@{yesterday}".
.TP
\-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.
.\" 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\-CONFIG" "1" "07/02/2007" "Git 1.5.2.2.646.g71e55" "Git Manual"
+.TH "GIT\-CONFIG" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
Common unit suffixes of \fIk\fR, \fIm\fR, or \fIg\fR are supported.
.TP
-core.excludeFile
+core.excludesfile
In addition to \fI.gitignore\fR (per\-directory) and \fI.git/info/exclude\fR, git looks into this file for patterns of files which are not meant to be tracked. See \fBgitignore\fR(5).
.TP
alias.*
.\" 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\-FORMAT\-PATCH" "1" "06/16/2007" "Git 1.5.2.1.255.gca6c0" "Git Manual"
+.TH "GIT\-FORMAT\-PATCH" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
Note that you would need to include the leading dot . if you want a filename like 0001\-description\-of\-my\-change.patch, and the first letter does not have to be a dot. Leaving it empty would not add any suffix.
.SH "CONFIGURATION"
-You can specify extra mail header lines to be added to each message in the repository configuration. Also you can specify the default suffix different from the built\-in one:
+You can specify extra mail header lines to be added to each message in the repository configuration. You can also specify new defaults for the subject prefix and file suffix.
.sp
.nf
[format]
headers = "Organization: git\-foo\\n"
+ subjectprefix = CHANGE
suffix = .txt
.fi
.SH "EXAMPLES"
.\" 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\-FSCK" "1" "06/16/2007" "Git 1.5.2.2.236.g952c8" "Git Manual"
+.TH "GIT\-FSCK" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.sp
.nf
\fIgit\-fsck\fR [\-\-tags] [\-\-root] [\-\-unreachable] [\-\-cache] [\-\-no\-reflogs]
- [\-\-full] [\-\-strict] [\-\-verbose] [<object>*]
+ [\-\-full] [\-\-strict] [\-\-verbose] [\-\-lost\-found] [<object>*]
.fi
.SH "DESCRIPTION"
Verifies the connectivity and validity of the objects in the database.
.TP
\-\-verbose
Be chatty.
+.TP
+\-\-lost\-found
+Write dangling refs into .git/commit/ or .git/other/, depending on type.
It tests SHA1 and general object sanity, and it does full tracking of the resulting reachability and everything else. It prints out any corruption it finds (missing or bad objects), and if you use the \fI\-\-unreachable\fR flag it will also print out objects that exist but that aren't readable from any of the specified head nodes.
.\" 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\-INIT\-DB" "1" "06/16/2007" "Git 1.5.2.2.236.g952c8" "Git Manual"
+.TH "GIT\-INIT\-DB" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.SH "NAME"
git\-init\-db \- Creates an empty git repository
.SH "SYNOPSIS"
-\fIgit\-init\-db\fR [\-\-template=<template_directory>] [\-\-shared[=<permissions>]]
+\fIgit\-init\-db\fR [\-
q | \-\-quiet] [\-\-template=<template_directory>] [\-\-shared[=<permissions>]]
.SH "DESCRIPTION"
This is a synonym for \fBgit\-init\fR(1). Please refer to the documentation of that 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\-INIT" "1" "06/16/2007" "Git 1.5.2.2.236.g952c8" "Git Manual"
+.TH "GIT\-INIT" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.SH "NAME"
git\-init \- Create an empty git repository or reinitialize an existing one
.SH "SYNOPSIS"
-\fIgit\-init\fR [\-\-template=<template_directory>] [\-\-shared[=<permissions>]]
+\fIgit\-init\fR [\-
q | \-\-quiet] [\-\-template=<template_directory>] [\-\-shared[=<permissions>]]
.SH "OPTIONS"
.TP
+\-q, \-\-quiet
+Only print error and warning messages, all other output will be suppressed.
+.TP
\-\-template=<template_directory>
Provide the directory from which templates will be used. The default template directory is /usr/share/git\-core/templates.
.\" 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\-LOCAL\-FETCH" "1" "06/16/2007" "Git 1.5.2.2.236.g952c8" "Git Manual"
+.TH "GIT\-LOCAL\-FETCH" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
commit\-id path
.fi
.SH "DESCRIPTION"
+THIS COMMAND IS DEPRECATED.
+
Duplicates another git repository on a local system.
.SH "OPTIONS"
.TP
.\" 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" "06/16/2007" "Git 1.5.2.1.144.gabc40" "Git Manual"
+.TH "GIT\-REBASE" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.SH "SYNOPSIS"
.sp
.nf
-\fIgit\-rebase\fR [\-v] [\-\-merge] [\-C<n>] [\-\-onto <newbase>] <upstream> [<branch>]
+\fIgit\-rebase\fR [\-i | \-\-interactive] [\-v | \-\-verbose] [\-\-merge] [\-C<n>]
+ [\-p | \-\-preserve\-merges] [\-\-onto <newbase>] <upstream> [<branch>]
\fIgit\-rebase\fR \-\-continue | \-\-skip | \-\-abort
.fi
.SH "DESCRIPTION"
.TP
\-C<n>
Ensure at least <n> lines of surrounding context match before and after each change. When fewer lines of surrounding context exist they all must match. By default no context is ever ignored.
+.TP
+\-i, \-\-interactive
+Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing.
+.TP
+\-p, \-\-preserve\-merges
+Instead of ignoring merges, try to recreate them. This option only works in interactive mode.
.SH "MERGE STRATEGIES"
.TP
resolve
When the git rebase command is run, it will first execute a "pre\-rebase" hook if one exists. You can use this hook to do sanity checks and reject the rebase if it isn't appropriate. Please see the template pre\-rebase hook script for an example.
You must be in the top directory of your project to start (or continue) a rebase. Upon completion, <branch> will be the current branch.
-.SH "AUTHOR"
-Written by Junio C Hamano <junkio@cox.net>
+.SH "INTERACTIVE MODE"
+Rebasing interactively means that you have a chance to edit the commits which are rebased. You can reorder the commits, and you can remove them (weeding out bad or otherwise unwanted patches).
+
+The interactive mode is meant for this type of workflow:
+.TP 3
+1.
+have a wonderful idea
+.TP
+2.
+hack on the code
+.TP
+3.
+prepare a series for submission
+.TP
+4.
+submit
+
+where point 2. consists of several instances of
+.TP 3
+1.
+regular use
+.RS
+.TP 3
+1.
+finish something worthy of a commit
+.TP
+2.
+commit
+.RE
+.TP
+2.
+independent fixup
+.RS
+.TP 3
+1.
+realize that something does not work
+.TP
+2.
+fix that
+.TP
+3.
+commit it
+.RE
+Sometimes the thing fixed in b.2. cannot be amended to the not\-quite perfect commit it fixes, because that commit is buried deeply in a patch series. That is exactly what interactive rebase is for: use it after plenty of "a"s and "b"s, by rearranging and editing commits, and squashing multiple commits into one.
+
+Start it with the last commit you want to retain as\-is:
+.sp
+.nf
+git rebase \-i <after\-this\-commit>
+.fi
+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
+pick deadbee The oneline of this commit
+pick fa1afe1 The oneline of the next commit
+...
+.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.
+
+By replacing the command "pick" with the command "edit", you can tell git\-rebase to stop after applying that commit, so that you can edit the files and/or the commit message, amend the commit, and continue rebasing.
+
+If you want to fold two or more commits into one, replace the command "pick" with "squash" for the second and subsequent commit. If the commits had different authors, it will attribute the squashed commit to the author of the last commit.
+
+In both cases, or when a "pick" does not succeed (because of merge errors), the loop will stop to let you fix things, and you can continue the loop with git rebase \-\-continue.
+
+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
+$ git rebase \-i HEAD~5
+.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
+ X
+ \\
+ A\-\-\-M\-\-\-B
+ /
+\-\-\-o\-\-\-O\-\-\-P\-\-\-Q
+.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
+$ git rebase \-i \-p \-\-onto Q O
+.fi
+.SH "AUTHORS"
+Written by Junio C Hamano <junkio@cox.net> and Johannes E. Schindelin <johannes.schindelin@gmx.de>
.SH "DOCUMENTATION"
Documentation by Junio C Hamano and the git\-list <git@vger.kernel.org>.
.SH "GIT"
.\" 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\-RECEIVE\-PACK" "1" "06/16/2007" "Git 1.5.2.2.236.g952c8" "Git Manual"
+.TH "GIT\-RECEIVE\-PACK" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.nf
sha1\-old SP sha1\-new SP refname LF
.fi
-The refname value is relative to $GIT_DIR; e.g. for the master head this is "refs/heads/master". The two sha1 values before each refname are the object names for the refname before and after sha1\-old and sha1\-new should be valid objects in the repository.
+The refname value is relative to $GIT_DIR; e.g. for the master head this is "refs/heads/master". The two sha1 values before each refname are the object names for the refname before and after the update. Refs to be created will have sha1\-old equal to 0{40}, while refs to be deleted will have sha1\-new equal to 0{40}, otherwise sha1\-old and sha1\-new should be valid objects in the repository.
This hook is called before any refname is updated and before any fast\-forward checks are performed.
.nf
$GIT_DIR/hooks/update refname sha1\-old sha1\-new
.fi
-The refname parameter is relative to $GIT_DIR; e.g. for the master head this is "refs/heads/master". The two sha1 arguments are the object names for the refname before and after the update. Note that the hook is called before the refname is updated, or it should match what is recorded in refname.
+The refname parameter is relative to $GIT_DIR; e.g. for the master head this is "refs/heads/master". The two sha1 arguments are the object names for the refname before and after the update. Note that the hook is called before the refname is updated, so either sha1\-old is 0{40} (meaning there is no such ref yet), or it should match what is recorded in refname.
The hook should exit with non\-zero status if it wants to disallow updating the named ref. Otherwise it should exit with zero.
.nf
sha1\-old SP sha1\-new SP refname LF
.fi
-The refname value is relative to $GIT_DIR; e.g. for the master head this is "refs/heads/master". The two sha1 values before each refname are the object names for the refname before and after the update. Refs that were created will have sha1\-old equal to the repository.
+The refname value is relative to $GIT_DIR; e.g. for the master head this is "refs/heads/master". The two sha1 values before each refname are the object names for the refname before and after the update. Refs that were created will have sha1\-old equal to 0{40}, while refs that were deleted will have sha1\-new equal to 0{40}, otherwise sha1\-old and sha1\-new should be valid objects in the repository.
Using this hook, it is easy to generate mails describing the updates to the repository. This example script sends one mail message per ref listing the commits pushed to the repository:
.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\-REV\-LIST" "1" "06/21/2007" "Git 1.5.2.2.249.g45fd" "Git Manual"
+.TH "GIT\-REV\-LIST" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
Omit any commit that introduces the same change as another commit on the "other side" when the set of commits are limited with symmetric difference. For example, if you have two branches, A and B, a usual way to list all commits on only one side of them is with \-\-left\-right, like the example above in the description of that option. It however shows the commits that were cherry\-picked from the other branch (for example, "3rd on b" may be cherry\-picked from branch A). With this option, such pairs of commits are excluded from the output.
.TP
\-g, \-\-walk\-reflogs
-Instead of walking the commit ancestry chain, walk reflog entries from the most recent one to older ones. When this option is used you cannot specify commits to exclude (that is, \fI^commit\fR, \fIcommit1..commit2\fR, nor \fIcommit1\&...commit2\fR notations cannot be used). With \fI\-\-pretty\fR format other than oneline (for obvious reasons), this causes the output to have two extra lines of information used in the output. When the starting commit is specified as instead. Under \fI\-\-pretty=oneline\fR, the commit message is prefixed with this information on the same line.
+Instead of walking the commit ancestry chain, walk reflog entries from the most recent one to older ones. When this option is used you cannot specify commits to exclude (that is, \fI^commit\fR, \fIcommit1..commit2\fR, nor \fIcommit1\&...commit2\fR notations cannot be used). With \fI\-\-pretty\fR format other than oneline (for obvious reasons), this causes the output to have two extra lines of information taken from the reflog. By default, \fIcommit@{Nth}\fR notation is used in the output. When the starting commit is specified as instead. Under \fI\-\-pretty=oneline\fR, the commit message is prefixed with this information on the same line.
.TP
\-\-merge
After a failed merge, show refs that touch files having a conflict and don't exist on all heads to merge.
.\" 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\-SSH\-FETCH" "1" "06/16/2007" "Git 1.5.2.2.236.g952c8" "Git Manual"
+.TH "GIT\-SSH\-FETCH" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.SH "SYNOPSIS"
\fIgit\-ssh\-fetch\fR [\-c] [\-t] [\-a] [\-d] [\-v] [\-w filename] [\-\-recover] commit\-id url
.SH "DESCRIPTION"
+THIS COMMAND IS DEPRECATED.
+
Pulls from a remote repository over ssh connection, invoking git\-ssh\-upload on the other end. It functions identically to git\-ssh\-upload, aside from which end you run it on.
.SH "OPTIONS"
.TP
.\" 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\-SSH\-UPLOAD" "1" "06/16/2007" "Git 1.5.2.2.236.g952c8" "Git Manual"
+.TH "GIT\-SSH\-UPLOAD" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.SH "SYNOPSIS"
\fIgit\-ssh\-upload\fR [\-c] [\-t] [\-a] [\-d] [\-v] [\-w filename] [\-\-recover] commit\-id url
.SH "DESCRIPTION"
+THIS COMMAND IS DEPRECATED.
+
Pushes from a remote repository over ssh connection, invoking git\-ssh\-fetch on the other end. It functions identically to git\-ssh\-fetch, aside from which end you run it on.
.SH "OPTIONS"
.TP
--- /dev/null
+.\" ** You probably do not want to edit this file directly **
+.\" 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\-STASH" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
+git\-stash \- Stash the changes in a dirty working directory away
+.SH "SYNOPSIS"
+.sp
+.nf
+\fIgit\-stash\fR (save | list | show [<stash>] | apply [<stash>] | clear)
+.fi
+.SH "DESCRIPTION"
+Use \fIgit\-stash\fR when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.
+
+The modifications stashed away by this command can be listed with git\-stash list, inspected with git\-stash show, and restored (potentially on top of a different commit) with git\-stash apply. Calling git\-stash without any arguments is equivalent to git\-stash save.
+
+The latest stash you created is stored in $GIT_DIR/refs/stash; older stashes are found in the reflog of this reference and can be named using the usual reflog syntax (e.g. stash@{1} is the most recently created stash, stash@{2} is the one before it, stash@{2.hours.ago} is also possible).
+.SH "OPTIONS"
+.TP
+save
+Save your local modifications to a new \fIstash\fR, and run git\-reset \-\-hard to revert them. This is the default action when no subcommand is given.
+.TP
+list
+List the stashes that you currently have. Each \fIstash\fR is listed with its name (e.g. stash@{0} is the latest stash, `stash@{1} is the one before, etc.), the name of the branch that was current when the stash was made, and a short description of the commit the stash was based on.
+.sp
+.nf
+stash@{0}: submit: 6ebd0e2... Add git\-stash
+stash@{1}: master: 9cc0589... Merge branch 'master' of gfi
+.fi
+.TP
+show [<stash>]
+Show the changes recorded in the stash as a diff between the the stashed state and its original parent. When no <stash> is given, shows the latest one. By default, the command shows the diffstat, but it will accept any format known to git\-diff (e.g., git\-stash show \-p stash@{2} to view the second most recent stash in patch form).
+.TP
+apply [<stash>]
+Restore the changes recorded in the stash on top of the current working tree state. When no <stash> is given, applies the latest one. The working directory must match the index.
+
+This operation can fail with conflicts; you need to resolve them by hand in the working tree.
+.TP
+clear
+Remove all the stashed states. Note that those states will then be subject to pruning, and may be difficult or impossible to recover.
+.SH "DISCUSSION"
+A stash is represented as a commit whose tree records the state of the working directory, and its first parent is the commit at HEAD when the stash was created. The tree of the second parent records the state of the index when the stash is made, and it is made a child of the HEAD commit. The ancestry graph looks like this:
+.sp
+.nf
+ .\-\-\-\-W
+ / /
+...\-\-H\-\-\-\-I
+.fi
+where H is the HEAD commit, I is a commit that records the state of the index, and W is a commit that records the state of the working tree.
+.SH "EXAMPLES"
+.TP
+Pulling into a dirty tree
+When you are in the middle of something, you learn that there are upstream changes that are possibly relevant to what you are doing. When your local changes do not conflict with the changes in the upstream, a simple git pull will let you move forward.
+
+However, there are cases in which your local changes do conflict with the upstream changes, and git pull refuses to overwrite your changes. In such a case, you can stash your changes away, perform a pull, and then unstash, like this:
+.sp
+.nf
+$ git pull
+...
+file foobar not up to date, cannot merge.
+$ git stash
+$ git pull
+$ git stash apply
+.fi
+.TP
+Interrupted workflow
+When you are in the middle of something, your boss comes in and demands that you fix something immediately. Traditionally, you would make a commit to a temporary branch to store your changes away, and return to your original branch to make the emergency fix, like this:
+.sp
+.nf
+... hack hack hack ...
+$ git checkout \-b my_wip
+$ git commit \-a \-m "WIP"
+$ git checkout master
+$ edit emergency fix
+$ git commit \-a \-m "Fix in a hurry"
+$ git checkout my_wip
+$ git reset \-\-soft HEAD^
+... continue hacking ...
+.fi
+You can use git\-stash to simplify the above, like this:
+.sp
+.nf
+... hack hack hack ...
+$ git stash
+$ edit emergency fix
+$ git commit \-a \-m "Fix in a hurry"
+$ git stash apply
+... continue hacking ...
+.fi
+.SH "SEE ALSO"
+\fBgit\-checkout\fR(1), \fBgit\-commit\fR(1), \fBgit\-reflog\fR(1), \fBgit\-reset\fR(1)
+.SH "AUTHOR"
+Written by Nanako Shiraishi <nanako3@bluebottle.com>
+.SH "GIT"
+Part of the \fBgit\fR(7) suite
+
.\" 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\-SUBMODULE" "1" "06/16/2007" "Git 1.5.2.2.236.g952c8" "Git Manual"
+.TH "GIT\-SUBMODULE" "1" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.SH "NAME"
git\-submodule \- Initialize, update or inspect submodules
.SH "SYNOPSIS"
-\fIgit\-submodule\fR [\-\-quiet] [\-\-cached] [status|init|update] [\-\-] [<path>\&...]
+\fIgit\-submodule\fR [\-\-quiet] [\-
b branch] add <repository> [<path>] \fIgit\-submodule\fR [\-\-quiet] [\-\-cached] [status|init|update] [\-\-] [<path>\&...]
.SH "COMMANDS"
.TP
+add
+Add the given repository as a submodule at the given path to the changeset to be committed next. In particular, the repository is cloned at the specified path, added to the changeset and registered in .gitmodules. If no path is specified, the path is deduced from the repository specification.
+.TP
status
Show the status of the submodules. This will print the SHA\-1 of the currently checked out commit for each submodule, along with the submodule path and the output of \fBgit\-describe\fR(1) for the SHA\-1. Each SHA\-1 will be prefixed with \- if the submodule is not initialized and + if the currently checked out submodule commit does not match the SHA\-1 found in the index of the containing repository. This command is the default command for git\-submodule.
.TP
\-q, \-\-quiet
Only print error messages.
.TP
+\-b, \-\-branch
+Branch of repository to add as submodule.
+.TP
\-\-cached
Display the SHA\-1 stored in the index, not the SHA\-1 of the currently checked out submodule commit. This option is only valid for the status command.
.TP
.\" 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" "07/02/2007" "Git 1.5.2.2.646.g71e55" "Git Manual"
+.TH "GIT" "7" "07/03/2007" "Git 1.5.3.rc0" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
\fBgit\-show\fR(1)
Show various types of objects.
.TP
+\fBgit\-stash\fR(1)
+Stash the changes in a dirty working directory away.
+.TP
\fBgit\-status\fR(1)
Show the working tree status.
.TP
projects / git.git / commitdiff