зеркало из https://github.com/microsoft/git.git
Merge branch 'np/addcommit'
* np/addcommit: git-commit: allow --only to lose what was staged earlier. Documentation/git-commit: rewrite to make it more end-user friendly. make 'git add' a first class user friendly interface to the index
This commit is contained in:
Junio C Hamano
Коммит
78ba00407c
|
|
@ -3,7 +3,7 @@ git-add(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-add - Add files to the index file
|
||||
git-add - Add file contents to the changeset to be committed next
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
@ -11,16 +11,31 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
A simple wrapper for git-update-index to add files to the index,
|
||||
for people used to do "cvs add".
|
||||
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.
|
||||
|
||||
It only adds non-ignored files, to add ignored files use
|
||||
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 'git status' command can be used to obtain a summary of what is included
|
||||
for the next commit.
|
||||
|
||||
This command only adds non-ignored files, to add ignored files use
|
||||
"git update-index --add".
|
||||
|
||||
Please see gitlink:git-commit[1] for alternative ways to add content to a
|
||||
commit.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
<file>...::
|
||||
Files to add to the index (see gitlink:git-ls-files[1]).
|
||||
Files to add content from.
|
||||
|
||||
-n::
|
||||
Don't actually add the file(s), just show if they exist.
|
||||
|
|
@ -34,27 +49,12 @@ OPTIONS
|
|||
for command-line options).
|
||||
|
||||
|
||||
DISCUSSION
|
||||
----------
|
||||
|
||||
The list of <file> given to the command is fed to `git-ls-files`
|
||||
command to list files that are not registered in the index and
|
||||
are not ignored/excluded by `$GIT_DIR/info/exclude` file or
|
||||
`.gitignore` file in each directory. This means two things:
|
||||
|
||||
. You can put the name of a directory on the command line, and
|
||||
the command will add all files in it and its subdirectories;
|
||||
|
||||
. Giving the name of a file that is already in index does not
|
||||
run `git-update-index` on that path.
|
||||
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
git-add Documentation/\\*.txt::
|
||||
|
||||
Adds all `\*.txt` files that are not in the index under
|
||||
`Documentation` directory and its subdirectories.
|
||||
Adds content from all `\*.txt` files under `Documentation`
|
||||
directory and its subdirectories.
|
||||
+
|
||||
Note that the asterisk `\*` is quoted from the shell in this
|
||||
example; this lets the command to include the files from
|
||||
|
|
@ -62,15 +62,18 @@ subdirectories of `Documentation/` directory.
|
|||
|
||||
git-add git-*.sh::
|
||||
|
||||
Adds all git-*.sh scripts that are not in the index.
|
||||
Considers adding content from all git-*.sh scripts.
|
||||
Because this example lets shell expand the asterisk
|
||||
(i.e. you are listing the files explicitly), it does not
|
||||
add `subdir/git-foo.sh` to the index.
|
||||
consider `subdir/git-foo.sh`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
gitlink:git-status[1]
|
||||
gitlink:git-rm[1]
|
||||
gitlink:git-ls-files[1]
|
||||
gitlink:git-mv[1]
|
||||
gitlink:git-commit[1]
|
||||
gitlink:git-update-index[1]
|
||||
|
||||
Author
|
||||
------
|
||||
|
|
|
|||
|
|
@ -14,25 +14,41 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Updates the index file for given paths, or all modified files if
|
||||
'-a' is specified, and makes a commit object. The command specified
|
||||
by either the VISUAL or EDITOR environment variables are used to edit
|
||||
the commit log message.
|
||||
Use 'git commit' when you want to record your changes into the repository
|
||||
along with a log message describing what the commit is about. All changes
|
||||
to be committed must be explicitly identified using one of the following
|
||||
methods:
|
||||
|
||||
Several environment variable are used during commits. They are
|
||||
documented in gitlink:git-commit-tree[1].
|
||||
1. by using gitlink:git-add[1] to incrementally "add" changes to the
|
||||
next commit before using the 'commit' command (Note: even modified
|
||||
files must be "added");
|
||||
|
||||
2. by using gitlink:git-rm[1] to identify content removal for the next
|
||||
commit, again before using the 'commit' command;
|
||||
|
||||
3. by directly listing files containing changes to be committed as arguments
|
||||
to the 'commit' command, in which cases only those files alone will be
|
||||
considered for the commit;
|
||||
|
||||
4. by using the -a switch with the 'commit' command to automatically "add"
|
||||
changes from all known files i.e. files that have already been committed
|
||||
before, and perform the actual commit.
|
||||
|
||||
The gitlink:git-status[1] command can be used to obtain a
|
||||
summary of what is included by any of the above for the next
|
||||
commit by giving the same set of parameters you would give to
|
||||
this command.
|
||||
|
||||
If you make a commit and then found a mistake immediately after
|
||||
that, you can recover from it with gitlink:git-reset[1].
|
||||
|
||||
This command can run `commit-msg`, `pre-commit`, and
|
||||
`post-commit` hooks. See link:hooks.html[hooks] for more
|
||||
information.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
-a|--all::
|
||||
Update all paths in the index file. This flag notices
|
||||
files that have been modified and deleted, but new files
|
||||
you have not told git about are not affected.
|
||||
Tell the command to automatically stage files that have
|
||||
been modified and deleted, but new files you have not
|
||||
told git about are not affected.
|
||||
|
||||
-c or -C <commit>::
|
||||
Take existing commit object, and reuse the log message
|
||||
|
|
@ -55,16 +71,13 @@ OPTIONS
|
|||
-s|--signoff::
|
||||
Add Signed-off-by line at the end of the commit message.
|
||||
|
||||
-v|--verify::
|
||||
Look for suspicious lines the commit introduces, and
|
||||
abort committing if there is one. The definition of
|
||||
'suspicious lines' is currently the lines that has
|
||||
trailing whitespaces, and the lines whose indentation
|
||||
has a SP character immediately followed by a TAB
|
||||
character. This is the default.
|
||||
|
||||
-n|--no-verify::
|
||||
The opposite of `--verify`.
|
||||
--no-verify::
|
||||
By default, the command looks for suspicious lines the
|
||||
commit introduces, and aborts committing if there is one.
|
||||
The definition of 'suspicious lines' is currently the
|
||||
lines that has trailing whitespaces, and the lines whose
|
||||
indentation has a SP character immediately followed by a
|
||||
TAB character. This option turns off the check.
|
||||
|
||||
-e|--edit::
|
||||
The message taken from file with `-F`, command line with
|
||||
|
|
@ -95,69 +108,137 @@ but can be used to amend a merge commit.
|
|||
--
|
||||
|
||||
-i|--include::
|
||||
Instead of committing only the files specified on the
|
||||
command line, update them in the index file and then
|
||||
commit the whole index. This is the traditional
|
||||
behavior.
|
||||
|
||||
-o|--only::
|
||||
Commit only the files specified on the command line.
|
||||
This format cannot be used during a merge, nor when the
|
||||
index and the latest commit does not match on the
|
||||
specified paths to avoid confusion.
|
||||
Before making a commit out of staged contents so far,
|
||||
stage the contents of paths given on the command line
|
||||
as well. This is usually not what you want unless you
|
||||
are concluding a conflicted merge.
|
||||
|
||||
\--::
|
||||
Do not interpret any more arguments as options.
|
||||
|
||||
<file>...::
|
||||
Files to be committed. The meaning of these is
|
||||
different between `--include` and `--only`. Without
|
||||
either, it defaults `--only` semantics.
|
||||
|
||||
If you make a commit and then found a mistake immediately after
|
||||
that, you can recover from it with gitlink:git-reset[1].
|
||||
When files are given on the command line, the command
|
||||
commits the contents of the named files, without
|
||||
recording the changes already staged. The contents of
|
||||
these files are also staged for the next commit on top
|
||||
of what have been staged before.
|
||||
|
||||
|
||||
Discussion
|
||||
----------
|
||||
EXAMPLES
|
||||
--------
|
||||
When recording your own work, the contents of modified files in
|
||||
your working tree are temporarily stored to a staging area
|
||||
called the "index" with gitlink:git-add[1]. Removal
|
||||
of a file is staged with gitlink:git-rm[1]. After building the
|
||||
state to be committed incrementally with these commands, `git
|
||||
commit` (without any pathname parameter) is used to record what
|
||||
has been staged so far. This is the most basic form of the
|
||||
command. An example:
|
||||
|
||||
`git commit` without _any_ parameter commits the tree structure
|
||||
recorded by the current index file. This is a whole-tree commit
|
||||
even the command is invoked from a subdirectory.
|
||||
------------
|
||||
$ edit hello.c
|
||||
$ git rm goodbye.c
|
||||
$ git add hello.c
|
||||
$ git commit
|
||||
------------
|
||||
|
||||
`git commit --include paths...` is equivalent to
|
||||
////////////
|
||||
We should fix 'git rm' to remove goodbye.c from both index and
|
||||
working tree for the above example.
|
||||
////////////
|
||||
|
||||
git update-index --remove paths...
|
||||
git commit
|
||||
Instead of staging files after each individual change, you can
|
||||
tell `git commit` to notice the changes to the files whose
|
||||
contents are tracked in
|
||||
your working tree and do corresponding `git add` and `git rm`
|
||||
for you. That is, this example does the same as the earlier
|
||||
example if there is no other change in your working tree:
|
||||
|
||||
That is, update the specified paths to the index and then commit
|
||||
the whole tree.
|
||||
------------
|
||||
$ edit hello.c
|
||||
$ rm goodbye.c
|
||||
$ git commit -a
|
||||
------------
|
||||
|
||||
`git commit paths...` largely bypasses the index file and
|
||||
commits only the changes made to the specified paths. It has
|
||||
however several safety valves to prevent confusion.
|
||||
The command `git commit -a` first looks at your working tree,
|
||||
notices that you have modified hello.c and removed goodbye.c,
|
||||
and performs necessary `git add` and `git rm` for you.
|
||||
|
||||
. It refuses to run during a merge (i.e. when
|
||||
`$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
|
||||
that the traditional semantics now needs -i flag.
|
||||
After staging changes to many files, you can alter the order the
|
||||
changes are recorded in, by giving pathnames to `git commit`.
|
||||
When pathnames are given, the command makes a commit that
|
||||
only records the changes made to the named paths:
|
||||
|
||||
. It refuses to run if named `paths...` are different in HEAD
|
||||
and the index (ditto about reminding). Added paths are OK.
|
||||
This is because an earlier `git diff` (not `git diff HEAD`)
|
||||
would have shown the differences since the last `git
|
||||
update-index paths...` to the user, and an inexperienced user
|
||||
may mistakenly think that the changes between the index and
|
||||
the HEAD (i.e. earlier changes made before the last `git
|
||||
update-index paths...` was done) are not being committed.
|
||||
------------
|
||||
$ edit hello.c hello.h
|
||||
$ git add hello.c hello.h
|
||||
$ edit Makefile
|
||||
$ git commit Makefile
|
||||
------------
|
||||
|
||||
. It reads HEAD commit into a temporary index file, updates the
|
||||
specified `paths...` and makes a commit. At the same time,
|
||||
the real index file is also updated with the same `paths...`.
|
||||
This makes a commit that records the modification to `Makefile`.
|
||||
The changes staged for `hello.c` and `hello.h` are not included
|
||||
in the resulting commit. However, their changes are not lost --
|
||||
they are still staged and merely held back. After the above
|
||||
sequence, if you do:
|
||||
|
||||
`git commit --all` updates the index file with _all_ changes to
|
||||
the working tree, and makes a whole-tree commit, regardless of
|
||||
which subdirectory the command is invoked in.
|
||||
------------
|
||||
$ git commit
|
||||
------------
|
||||
|
||||
this second commit would record the changes to `hello.c` and
|
||||
`hello.h` as expected.
|
||||
|
||||
After a merge (initiated by either gitlink:git-merge[1] or
|
||||
gitlink:git-pull[1]) stops because of conflicts, cleanly merged
|
||||
paths are already staged to be committed for you, and paths that
|
||||
conflicted are left in unmerged state. You would have to first
|
||||
check which paths are conflicting with gitlink:git-status[1]
|
||||
and after fixing them manually in your working tree, you would
|
||||
stage the result as usual with gitlink:git-add[1]:
|
||||
|
||||
------------
|
||||
$ git status | grep unmerged
|
||||
unmerged: hello.c
|
||||
$ edit hello.c
|
||||
$ git add hello.c
|
||||
------------
|
||||
|
||||
After resolving conflicts and staging the result, `git ls-files -u`
|
||||
would stop mentioning the conflicted path. When you are done,
|
||||
run `git commit` to finally record the merge:
|
||||
|
||||
------------
|
||||
$ git commit
|
||||
------------
|
||||
|
||||
As with the case to record your own changes, you can use `-a`
|
||||
option to save typing. One difference is that during a merge
|
||||
resolution, you cannot use `git commit` with pathnames to
|
||||
alter the order the changes are committed, because the merge
|
||||
should be recorded as a single commit. In fact, the command
|
||||
refuses to run when given pathnames (but see `-i` option).
|
||||
|
||||
|
||||
ENVIRONMENT VARIABLES
|
||||
---------------------
|
||||
The command specified by either the VISUAL or EDITOR environment
|
||||
variables is used to edit the commit log message.
|
||||
|
||||
HOOKS
|
||||
-----
|
||||
This command can run `commit-msg`, `pre-commit`, and
|
||||
`post-commit` hooks. See link:hooks.html[hooks] for more
|
||||
information.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
gitlink:git-add[1],
|
||||
gitlink:git-rm[1],
|
||||
gitlink:git-mv[1],
|
||||
gitlink:git-merge[1],
|
||||
gitlink:git-commit-tree[1]
|
||||
|
||||
Author
|
||||
------
|
||||
|
|
|
|||
|
|
@ -87,14 +87,48 @@ thorough description. Tools that turn commits into email, for
|
|||
example, use the first line on the Subject line and the rest of the
|
||||
commit in the body.
|
||||
|
||||
To add a new file, first create the file, then
|
||||
|
||||
------------------------------------------------
|
||||
$ git add path/to/new/file
|
||||
------------------------------------------------
|
||||
Git tracks content not files
|
||||
----------------------------
|
||||
|
||||
then commit as usual. No special command is required when removing a
|
||||
file; just remove it, then tell `commit` about the file as usual.
|
||||
With git you have to explicitly "add" all the changed _content_ you
|
||||
want to commit together. This can be done in a few different ways:
|
||||
|
||||
1) By using 'git add <file_spec>...'
|
||||
|
||||
This can be performed multiple times before a commit. Note that this
|
||||
is not only for adding new files. Even modified files must be
|
||||
added to the set of changes about to be committed. The "git status"
|
||||
command gives you a summary of what is included so far for the
|
||||
next commit. When done you should use the 'git commit' command to
|
||||
make it real.
|
||||
|
||||
Note: don't forget to 'add' a file again if you modified it after the
|
||||
first 'add' and before 'commit'. Otherwise only the previous added
|
||||
state of that file will be committed. This is because git tracks
|
||||
content, so what you're really 'add'ing to the commit is the *content*
|
||||
of the file in the state it is in when you 'add' it.
|
||||
|
||||
2) By using 'git commit -a' directly
|
||||
|
||||
This is a quick way to automatically 'add' the content from all files
|
||||
that were modified since the previous commit, and perform the actual
|
||||
commit without having to separately 'add' them beforehand. This will
|
||||
not add content from new files i.e. files that were never added before.
|
||||
Those files still have to be added explicitly before performing a
|
||||
commit.
|
||||
|
||||
But here's a twist. If you do 'git commit <file1> <file2> ...' then only
|
||||
the changes belonging to those explicitly specified files will be
|
||||
committed, entirely bypassing the current "added" changes. Those "added"
|
||||
changes will still remain available for a subsequent commit though.
|
||||
|
||||
However, for normal usage you only have to remember 'git add' + 'git commit'
|
||||
and/or 'git commit -a'.
|
||||
|
||||
|
||||
Viewing the changelog
|
||||
---------------------
|
||||
|
||||
At any point you can view the history of your changes using
|
||||
|
||||
|
|
|
|||
|
|
@ -94,9 +94,6 @@ int cmd_add(int argc, const char **argv, const char *prefix)
|
|||
|
||||
newfd = hold_lock_file_for_update(&lock_file, get_index_file(), 1);
|
||||
|
||||
if (read_cache() < 0)
|
||||
die("index file corrupt");
|
||||
|
||||
for (i = 1; i < argc; i++) {
|
||||
const char *arg = argv[i];
|
||||
|
||||
|
|
@ -131,6 +128,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)
|
|||
return 0;
|
||||
}
|
||||
|
||||
if (read_cache() < 0)
|
||||
die("index file corrupt");
|
||||
|
||||
for (i = 0; i < dir.nr; i++)
|
||||
add_file_to_index(dir.entries[i]->name, verbose);
|
||||
|
||||
|
|
|
|||
|
|
@ -350,19 +350,9 @@ t,)
|
|||
refuse_partial "Cannot do a partial commit during a merge."
|
||||
fi
|
||||
TMP_INDEX="$GIT_DIR/tmp-index$$"
|
||||
if test -z "$initial_commit"
|
||||
then
|
||||
# make sure index is clean at the specified paths, or
|
||||
# they are additions.
|
||||
dirty_in_index=`git-diff-index --cached --name-status \
|
||||
--diff-filter=DMTU HEAD -- "$@"`
|
||||
test -z "$dirty_in_index" ||
|
||||
refuse_partial "Different in index and the last commit:
|
||||
$dirty_in_index"
|
||||
fi
|
||||
commit_only=`git-ls-files --error-unmatch -- "$@"` || exit
|
||||
|
||||
# Build the temporary index and update the real index
|
||||
# Build a temporary index and update the real index
|
||||
# the same way.
|
||||
if test -z "$initial_commit"
|
||||
then
|
||||
|
|
|
|||
|
|
@ -163,7 +163,7 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
|
|||
int i;
|
||||
if (q->nr)
|
||||
wt_status_print_header("Changed but not updated",
|
||||
"use git-update-index to mark for commit");
|
||||
"use git-add on files to include for commit");
|
||||
for (i = 0; i < q->nr; i++)
|
||||
wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
|
||||
if (q->nr)
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче