Merge branch 'master' of git://linux-nfs.org/~bfields/git
* 'master' of git://linux-nfs.org/~bfields/git: documentation: use the word "index" in the git-add manual page user-manual: mention git-gui user-manual: mention git stash user-manual: update for new default --track behavior
This commit is contained in:
Junio C Hamano
commit
a2c3db8d22
@ -3,7 +3,7 @@ git-add(1)
|
||||
|
||||
NAME
|
||||
----
|
||||
git-add - Add file contents to the changeset to be committed next
|
||||
git-add - Add file contents to the index
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
@ -11,24 +11,27 @@ SYNOPSIS
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
All the changed file contents to be committed together in a single set
|
||||
of changes must be "added" with the 'add' command before using the
|
||||
'commit' command. This is not only for adding new files. Even modified
|
||||
files must be added to the set of changes about to be committed.
|
||||
This command adds the current content of new or modified files to the
|
||||
index, thus staging that content for inclusion in the next commit.
|
||||
|
||||
This command can be performed multiple times before a commit. The added
|
||||
content corresponds to the state of specified file(s) at the time the
|
||||
'add' command is used. This means the 'commit' command will not consider
|
||||
subsequent changes to already added content if it is not added again before
|
||||
the commit.
|
||||
The "index" holds a snapshot of the content of the working tree, and it
|
||||
is this snapshot that is taken as the contents of the next commit. Thus
|
||||
after making any changes to the working directory, and before running
|
||||
the commit command, you must use the 'add' command to add any new or
|
||||
modified files to the index.
|
||||
|
||||
The 'git status' command can be used to obtain a summary of what is included
|
||||
for the next commit.
|
||||
This command can be performed multiple times before a commit. It only
|
||||
adds the content of the specified file(s) at the time the add command is
|
||||
run; if you want subsequent changes included in the next commit, then
|
||||
you must run 'git add' again to add the new content to the index.
|
||||
|
||||
This 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 'git status' command can be used to obtain a summary of which
|
||||
files have changes that are staged for the next commit.
|
||||
|
||||
The 'add' 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.
|
||||
|
||||
Please see gitlink:git-commit[1] for alternative ways to add content to a
|
||||
commit.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
Git User's Manual (for version 1.5.1 or newer)
|
||||
Git User's Manual (for version 1.5.3 or newer)
|
||||
______________________________________________
|
||||
|
||||
|
||||
@ -1079,6 +1079,11 @@ $ git diff HEAD # difference between HEAD and working tree; what
|
||||
$ git status # a brief per-file summary of the above.
|
||||
-------------------------------------------------
|
||||
|
||||
You can also use gitlink:git-gui[1] to create commits, view changes in
|
||||
the index and the working tree files, and individually select diff hunks
|
||||
for inclusion in the index (by right-clicking on the diff hunk and
|
||||
choosing "Stage Hunk For Commit").
|
||||
|
||||
[[creating-good-commit-messages]]
|
||||
Creating good commit messages
|
||||
-----------------------------
|
||||
@ -1484,6 +1489,38 @@ $ git show HEAD^:path/to/file
|
||||
|
||||
which will display the given version of the file.
|
||||
|
||||
[[interrupted-work]]
|
||||
Temporarily setting aside work in progress
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
While you are in the middle of working on something complicated, you
|
||||
find an unrelated but obvious and trivial bug. You would like to fix it
|
||||
before continuing. You can use gitlink:git-stash[1] to save the current
|
||||
state of your work, and after fixing the bug (or, optionally after doing
|
||||
so on a different branch and then coming back), unstash the
|
||||
work-in-progress changes.
|
||||
|
||||
------------------------------------------------
|
||||
$ git stash "work in progress for foo feature"
|
||||
------------------------------------------------
|
||||
|
||||
This command will save your changes away to the `stash`, and
|
||||
reset your working tree and the index to match the tip of your
|
||||
current branch. Then you can make your fix as usual.
|
||||
|
||||
------------------------------------------------
|
||||
... edit and test ...
|
||||
$ git commit -a -m "blorpl: typofix"
|
||||
------------------------------------------------
|
||||
|
||||
After that, you can go back to what you were working on with
|
||||
`git stash apply`:
|
||||
|
||||
------------------------------------------------
|
||||
$ git stash apply
|
||||
------------------------------------------------
|
||||
|
||||
|
||||
[[ensuring-good-performance]]
|
||||
Ensuring good performance
|
||||
-------------------------
|
||||
@ -1667,24 +1704,19 @@ one step:
|
||||
$ git pull origin master
|
||||
-------------------------------------------------
|
||||
|
||||
In fact, "origin" is normally the default repository to pull from,
|
||||
and the default branch is normally the HEAD of the remote repository,
|
||||
so often you can accomplish the above with just
|
||||
In fact, if you have "master" checked out, then by default "git pull"
|
||||
merges from the HEAD branch of the origin repository. So often you can
|
||||
accomplish the above with just a simple
|
||||
|
||||
-------------------------------------------------
|
||||
$ git pull
|
||||
-------------------------------------------------
|
||||
|
||||
See the descriptions of the branch.<name>.remote and branch.<name>.merge
|
||||
options in gitlink:git-config[1] to learn how to control these defaults
|
||||
depending on the current branch. Also note that the --track option to
|
||||
gitlink:git-branch[1] and gitlink:git-checkout[1] can be used to
|
||||
automatically set the default remote branch to pull from at the time
|
||||
that a branch is created:
|
||||
|
||||
-------------------------------------------------
|
||||
$ git checkout --track -b maint origin/maint
|
||||
-------------------------------------------------
|
||||
More generally, a branch that is created from a remote branch will pull
|
||||
by default from that branch. See the descriptions of the
|
||||
branch.<name>.remote and branch.<name>.merge options in
|
||||
gitlink:git-config[1], and the discussion of the --track option in
|
||||
gitlink:git-checkout[1], to learn how to control these defaults.
|
||||
|
||||
In addition to saving you keystrokes, "git pull" also helps you by
|
||||
producing a default commit message documenting the branch and
|
||||
@ -2479,8 +2511,10 @@ $ gitk origin..mywork &
|
||||
|
||||
And browse through the list of patches in the mywork branch using gitk,
|
||||
applying them (possibly in a different order) to mywork-new using
|
||||
cherry-pick, and possibly modifying them as you go using commit
|
||||
--amend.
|
||||
cherry-pick, and possibly modifying them as you go using commit --amend.
|
||||
The git-gui[1] command may also help as it allows you to individually
|
||||
select diff hunks for inclusion in the index (by right-clicking on the
|
||||
diff hunk and choosing "Stage Hunk for Commit").
|
||||
|
||||
Another technique is to use git-format-patch to create a series of
|
||||
patches, then reset the state to before the patches:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user