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:
commit
a2c3db8d22
@ -3,7 +3,7 @@ git-add(1)
|
|||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-add - Add file contents to the changeset to be committed next
|
git-add - Add file contents to the index
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
@ -11,24 +11,27 @@ SYNOPSIS
|
|||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
All the changed file contents to be committed together in a single set
|
This command adds the current content of new or modified files to the
|
||||||
of changes must be "added" with the 'add' command before using the
|
index, thus staging that content for inclusion in the next commit.
|
||||||
'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 can be performed multiple times before a commit. The added
|
The "index" holds a snapshot of the content of the working tree, and it
|
||||||
content corresponds to the state of specified file(s) at the time the
|
is this snapshot that is taken as the contents of the next commit. Thus
|
||||||
'add' command is used. This means the 'commit' command will not consider
|
after making any changes to the working directory, and before running
|
||||||
subsequent changes to already added content if it is not added again before
|
the commit command, you must use the 'add' command to add any new or
|
||||||
the commit.
|
modified files to the index.
|
||||||
|
|
||||||
The 'git status' command can be used to obtain a summary of what is included
|
This command can be performed multiple times before a commit. It only
|
||||||
for the next commit.
|
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)
|
The 'git status' command can be used to obtain a summary of which
|
||||||
option, but they have to be
|
files have changes that are staged for the next commit.
|
||||||
explicitly and exactly specified from the command line. File globbing
|
|
||||||
and recursive behaviour do not add ignored files.
|
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
|
Please see gitlink:git-commit[1] for alternative ways to add content to a
|
||||||
commit.
|
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.
|
$ 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]]
|
||||||
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.
|
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]]
|
||||||
Ensuring good performance
|
Ensuring good performance
|
||||||
-------------------------
|
-------------------------
|
||||||
@ -1667,24 +1704,19 @@ one step:
|
|||||||
$ git pull origin master
|
$ git pull origin master
|
||||||
-------------------------------------------------
|
-------------------------------------------------
|
||||||
|
|
||||||
In fact, "origin" is normally the default repository to pull from,
|
In fact, if you have "master" checked out, then by default "git pull"
|
||||||
and the default branch is normally the HEAD of the remote repository,
|
merges from the HEAD branch of the origin repository. So often you can
|
||||||
so often you can accomplish the above with just
|
accomplish the above with just a simple
|
||||||
|
|
||||||
-------------------------------------------------
|
-------------------------------------------------
|
||||||
$ git pull
|
$ git pull
|
||||||
-------------------------------------------------
|
-------------------------------------------------
|
||||||
|
|
||||||
See the descriptions of the branch.<name>.remote and branch.<name>.merge
|
More generally, a branch that is created from a remote branch will pull
|
||||||
options in gitlink:git-config[1] to learn how to control these defaults
|
by default from that branch. See the descriptions of the
|
||||||
depending on the current branch. Also note that the --track option to
|
branch.<name>.remote and branch.<name>.merge options in
|
||||||
gitlink:git-branch[1] and gitlink:git-checkout[1] can be used to
|
gitlink:git-config[1], and the discussion of the --track option in
|
||||||
automatically set the default remote branch to pull from at the time
|
gitlink:git-checkout[1], to learn how to control these defaults.
|
||||||
that a branch is created:
|
|
||||||
|
|
||||||
-------------------------------------------------
|
|
||||||
$ git checkout --track -b maint origin/maint
|
|
||||||
-------------------------------------------------
|
|
||||||
|
|
||||||
In addition to saving you keystrokes, "git pull" also helps you by
|
In addition to saving you keystrokes, "git pull" also helps you by
|
||||||
producing a default commit message documenting the branch and
|
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,
|
And browse through the list of patches in the mywork branch using gitk,
|
||||||
applying them (possibly in a different order) to mywork-new using
|
applying them (possibly in a different order) to mywork-new using
|
||||||
cherry-pick, and possibly modifying them as you go using commit
|
cherry-pick, and possibly modifying them as you go using commit --amend.
|
||||||
--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
|
Another technique is to use git-format-patch to create a series of
|
||||||
patches, then reset the state to before the patches:
|
patches, then reset the state to before the patches:
|
||||||
|
Loading…
Reference in New Issue
Block a user