specifying `dir` will record not just a file `dir/file1`
modified in the working tree, a file `dir/file2` added to
the working tree, but also a file `dir/file3` removed from
- the working tree. Note that older versions of Git used
+ the working tree). Note that older versions of Git used
to ignore removed files; use `--no-all` option if you want
- to add modified or new files but ignore removed ones.
+ to add modified or new files but ignore removed ones.
+
For more details about the <pathspec> syntax, see the 'pathspec' entry
in linkgit:gitglossary[7].
--no-ignore-removal::
Update the index not only where the working tree has a file
matching <pathspec> but also where the index already has an
- entry. This adds, modifies, and removes index entries to
+ entry. This adds, modifies, and removes index entries to
match the working tree.
+
If no <pathspec> is given when `-A` option is used, all
--------
* Adds content from all `*.txt` files under `Documentation` directory
-and its subdirectories:
+ and its subdirectories:
+
------------
$ git add Documentation/\*.txt
------------
+
<1> This step and the next one could be combined into a single step with
-"checkout -b my2.6.14 v2.6.14".
+ "checkout -b my2.6.14 v2.6.14".
Delete an unneeded branch::
+
------------
+
<1> Delete the remote-tracking branches "todo", "html" and "man". The next
-'fetch' or 'pull' will create them again unless you configure them not to.
-See linkgit:git-fetch[1].
+ 'fetch' or 'pull' will create them again unless you configure them not to.
+ See linkgit:git-fetch[1].
<2> Delete the "test" branch even if the "master" branch (or whichever branch
-is currently checked out) does not have all commits from the test branch.
+ is currently checked out) does not have all commits from the test branch.
NOTES
------------
<1> creates a new branch 'foo', which refers to commit 'f', and then
-updates HEAD to refer to branch 'foo'. In other words, we'll no longer
-be in detached HEAD state after this command.
+ updates HEAD to refer to branch 'foo'. In other words, we'll no longer
+ be in detached HEAD state after this command.
<2> similarly creates a new branch 'foo', which refers to commit 'f',
-but leaves HEAD detached.
+ but leaves HEAD detached.
<3> creates a new tag 'foo', which refers to commit 'f',
-leaving HEAD detached.
+ leaving HEAD detached.
If we have moved away from commit 'f', then we must first recover its object
name (typically by using git reflog), and then we can create a reference to
--------
. The following sequence checks out the `master` branch, reverts
-the `Makefile` to two revisions back, deletes hello.c by
-mistake, and gets it back from the index.
+ the `Makefile` to two revisions back, deletes hello.c by
+ mistake, and gets it back from the index.
+
------------
$ git checkout master <1>
------------
. After working in the wrong branch, switching to the correct
-branch would be done using:
+ branch would be done using:
+
------------
$ git checkout mytopic
changes you made since the tip of the new branch.
. When a merge conflict happens during switching branches with
-the `-m` option, you would see something like this:
+ the `-m` option, you would see something like this:
+
------------
$ git checkout -m mytopic
$ git cherry-pick -Xpatience topic^ <4>
------------
<1> apply the change that would be shown by `git show topic^`.
-In this example, the patch does not apply cleanly, so
-information about the conflict is written to the index and
-working tree and no new commit results.
+ In this example, the patch does not apply cleanly, so
+ information about the conflict is written to the index and
+ working tree and no new commit results.
<2> summarize changes to be reconciled
<3> cancel the cherry-pick. In other words, return to the
-pre-cherry-pick state, preserving any local modifications you had in
-the working tree.
+ pre-cherry-pick state, preserving any local modifications
+ you had in the working tree.
<4> try to apply the change introduced by `topic^` again,
-spending extra time to avoid mistakes based on incorrectly matching
-context lines.
+ spending extra time to avoid mistakes based on incorrectly
+ matching context lines.
SEE ALSO
--------
+
<1> Changes in the working tree not yet staged for the next commit.
<2> Changes between the index and your last commit; what you
-would be committing if you run "git commit" without "-a" option.
+ would be committing if you run "git commit" without "-a" option.
<3> Changes in the working tree since your last commit; what you
-would be committing if you run "git commit -a"
+ would be committing if you run "git commit -a"
Comparing with arbitrary commits::
+
------------
+
<1> Instead of using the tip of the current branch, compare with the
-tip of "test" branch.
+ tip of "test" branch.
<2> Instead of comparing with the tip of "test" branch, compare with
-the tip of the current branch, but limit the comparison to the
-file "test".
+ the tip of the current branch, but limit the comparison to the
+ file "test".
<3> Compare the version before the last commit and the last commit.
Comparing branches::
<1> Changes between the tips of the topic and the master branches.
<2> Same as above.
<3> Changes that occurred on the master branch since when the topic
-branch was started off it.
+ branch was started off it.
Limiting the diff output::
+
------------
+
<1> Show only modification, rename, and copy, but not addition
-or deletion.
+ or deletion.
<2> Show only names and the nature of change, but not actual
-diff output.
+ diff output.
<3> Limit diff output to named subtrees.
Munging the diff output::
------------
+
<1> Spend extra cycles to find renames, copies and complete
-rewrites (very expensive).
+ rewrites (very expensive).
<2> Output diff in reverse.
SEE ALSO
because it is prefixed with a plus sign; `tmp` will not be.
* Peek at a remote's branch, without configuring the remote in your local
-repository:
+ repository:
+
------------------------------------------------
$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
"mailnews.wraplength" and set the value to 0.
3. Disable the use of format=flowed:
-Edit..Preferences..Advanced..Config Editor. Search for
-"mailnews.send_plaintext_flowed".
-Toggle it to make sure it is set to `false`.
+ Edit..Preferences..Advanced..Config Editor. Search for
+ "mailnews.send_plaintext_flowed".
+ Toggle it to make sure it is set to `false`.
After that is done, you should be able to compose email as you
otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc),
--------
* Extract commits between revisions R1 and R2, and apply them on top of
-the current branch using 'git am' to cherry-pick them:
+ the current branch using 'git am' to cherry-pick them:
+
------------
$ git format-patch -k --stdout R1..R2 | git am -3 -k
------------
* Extract all commits which are in the current branch but not in the
-origin branch:
+ origin branch:
+
------------
$ git format-patch origin
For each commit a separate file is created in the current directory.
* Extract all commits that lead to 'origin' since the inception of the
-project:
+ project:
+
------------
$ git format-patch --root origin
use it only when you know the recipient uses Git to apply your patch.
* Extract three topmost commits from the current branch and format them
-as e-mailable patches:
+ as e-mailable patches:
+
------------
$ git format-patch -3
* "man": use the 'man' program as usual,
* "woman": use 'emacsclient' to launch the "woman" mode in emacs
-(this only works starting with emacsclient versions 22),
+ (this only works starting with emacsclient versions 22),
* "konqueror": use 'kfmclient' to open the man page in a new konqueror
-tab (see 'Note about konqueror' below).
+ tab (see 'Note about konqueror' below).
Values for other tools can be used if there is a corresponding
`man.<tool>.cmd` configuration entry (see below).
------------
This:
-1. Creates an empty Git repository in a subdirectory called 'project'.
+1. Creates an empty Git repository in a subdirectory called 'project'.
+
-2. Imports the full contents of the head revision from the given p4
-depot path into a single commit in the Git branch 'refs/remotes/p4/master'.
+2. Imports the full contents of the head revision from the given p4
+ depot path into a single commit in the Git branch 'refs/remotes/p4/master'.
+
-3. Creates a local branch, 'master' from this remote and checks it out.
+3. Creates a local branch, 'master' from this remote and checks it out.
To reproduce the entire p4 history in Git, use the '@all' modifier on
the depot path:
------------
+
<1> You are happily working on something, and find the changes
-in these files are in good order. You do not want to see them
-when you run `git diff`, because you plan to work on other files
-and changes with these files are distracting.
+ in these files are in good order. You do not want to see them
+ when you run `git diff`, because you plan to work on other files
+ and changes with these files are distracting.
<2> Somebody asks you to pull, and the changes sound worthy of merging.
<3> However, you already dirtied the index (i.e. your index does
-not match the `HEAD` commit). But you know the pull you are going
-to make does not affect `frotz.c` or `filfre.c`, so you revert the
-index changes for these two files. Your changes in working tree
-remain there.
+ not match the `HEAD` commit). But you know the pull you are going
+ to make does not affect `frotz.c` or `filfre.c`, so you revert the
+ index changes for these two files. Your changes in working tree
+ remain there.
<4> Then you can pull and merge, leaving `frotz.c` and `filfre.c`
-changes still in the working tree.
+ changes still in the working tree.
Undo a commit and redo::
+
------------
+
<1> This is most often done when you remembered what you
-just committed is incomplete, or you misspelled your commit
-message, or both. Leaves working tree as it was before "reset".
+ just committed is incomplete, or you misspelled your commit
+ message, or both. Leaves working tree as it was before "reset".
<2> Make corrections to working tree files.
<3> "reset" copies the old head to `.git/ORIG_HEAD`; redo the
-commit by starting with its log message. If you do not need to
-edit the message further, you can give `-C` option instead.
+ commit by starting with its log message. If you do not need to
+ edit the message further, you can give `-C` option instead.
+
See also the `--amend` option to linkgit:git-commit[1].
------------
+
<1> You have made some commits, but realize they were premature
-to be in the `master` branch. You want to continue polishing
-them in a topic branch, so create `topic/wip` branch off of the
-current `HEAD`.
+ to be in the `master` branch. You want to continue polishing
+ them in a topic branch, so create `topic/wip` branch off of the
+ current `HEAD`.
<2> Rewind the master branch to get rid of those three commits.
<3> Switch to `topic/wip` branch and keep working.
------------
+
<1> The last three commits (`HEAD`, `HEAD^`, and `HEAD~2`) were bad
-and you do not want to ever see them again. Do *not* do this if
-you have already given these commits to somebody else. (See the
-"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
-the implications of doing so.)
+ and you do not want to ever see them again. Do *not* do this if
+ you have already given these commits to somebody else. (See the
+ "RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1]
+ for the implications of doing so.)
Undo a merge or pull::
+
------------
+
<1> Try to update from the upstream resulted in a lot of
-conflicts; you were not ready to spend a lot of time merging
-right now, so you decide to do that later.
+ conflicts; you were not ready to spend a lot of time merging
+ right now, so you decide to do that later.
<2> "pull" has not made merge commit, so `git reset --hard`
-which is a synonym for `git reset --hard HEAD` clears the mess
-from the index file and the working tree.
+ which is a synonym for `git reset --hard HEAD` clears the mess
+ from the index file and the working tree.
<3> Merge a topic branch into the current branch, which resulted
-in a fast-forward.
+ in a fast-forward.
<4> But you decided that the topic branch is not ready for public
-consumption yet. "pull" or "merge" always leaves the original
-tip of the current branch in `ORIG_HEAD`, so resetting hard to it
-brings your index file and the working tree back to that state,
-and resets the tip of the branch to that commit.
+ consumption yet. "pull" or "merge" always leaves the original
+ tip of the current branch in `ORIG_HEAD`, so resetting hard to it
+ brings your index file and the working tree back to that state,
+ and resets the tip of the branch to that commit.
Undo a merge or pull inside a dirty working tree::
+
------------
+
<1> Even if you may have local modifications in your
-working tree, you can safely say `git pull` when you know
-that the change in the other branch does not overlap with
-them.
+ working tree, you can safely say `git pull` when you know
+ that the change in the other branch does not overlap with
+ them.
<2> After inspecting the result of the merge, you may find
-that the change in the other branch is unsatisfactory. Running
-`git reset --hard ORIG_HEAD` will let you go back to where you
-were, but it will discard your local changes, which you do not
-want. `git reset --merge` keeps your local changes.
+ that the change in the other branch is unsatisfactory. Running
+ `git reset --hard ORIG_HEAD` will let you go back to where you
+ were, but it will discard your local changes, which you do not
+ want. `git reset --merge` keeps your local changes.
Interrupted workflow::
formatting are ignored.
2. The original format used by Greg Kroah-Hartman's 'send_lots_of_email.pl'
-script
+ script
+
This format expects the first line of the file to contain the "Cc:" value
and the "Subject:" of the message as the second line.
the old tag. In that case you can do one of two things:
. The sane thing.
-Just admit you screwed up, and use a different name. Others have
-already seen one tag-name, and if you keep the same name, you
-may be in the situation that two people both have "version X",
-but they actually have 'different' "X"'s. So just call it "X.1"
-and be done with it.
+ Just admit you screwed up, and use a different name. Others have
+ already seen one tag-name, and if you keep the same name, you
+ may be in the situation that two people both have "version X",
+ but they actually have 'different' "X"'s. So just call it "X.1"
+ and be done with it.
. The insane thing.
-You really want to call the new version "X" too, 'even though'
-others have already seen the old one. So just use 'git tag -f'
-again, as if you hadn't already published the old one.
+ You really want to call the new version "X" too, 'even though'
+ others have already seen the old one. So just use 'git tag -f'
+ again, as if you hadn't already published the old one.
However, Git does *not* (and it should not) change tags behind
users back. So if somebody already got the old tag, doing a
program pair is meant to be used to pull updates from a remote
repository. For push operations, see 'git send-pack'.
-
OPTIONS
-------
+
--
1. If the starting point is specified as `ref@{Nth}`, show the index
-format.
+ format.
+
2. If the starting point was specified as `ref@{now}`, show the
-timestamp format.
+ timestamp format.
+
3. If neither was used, but `--date` was given on the command line, show
-the timestamp in the format requested by `--date`.
+ the timestamp in the format requested by `--date`.
+
4. Otherwise, show the index format.
--
projects / thirdparty / git.git / commitdiff
