mirrors/git
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'np/addcommit'

Browse Source 
* 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
2006-12-13 11:08:20 -08:00
parent abcb49cb56 158d057789
commit 78ba00407c
6 changed files with 222 additions and 114 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
Documentation/git-add.txt
View File

@ -3,7 +3,7 @@ git-add(1)
NAME NAME
---- ----
git-add - Add files to the index file git-add - Add file contents to the changeset to be committed next
SYNOPSIS SYNOPSIS
-------- --------
@ -11,16 +11,31 @@ SYNOPSIS
DESCRIPTION DESCRIPTION
----------- -----------
A simple wrapper for git-update-index to add files to the index, All the changed file contents to be committed together in a single set
for people used to do "cvs add". 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". "git update-index --add".
Please see gitlink:git-commit[1] for alternative ways to add content to a
commit.
OPTIONS OPTIONS
------- -------
<file>...:: <file>...::
Files to add to the index (see gitlink:git-ls-files[1]). Files to add content from.
-n:: -n::
Don't actually add the file(s), just show if they exist. Don't actually add the file(s), just show if they exist.
@ -34,27 +49,12 @@ OPTIONS
for command-line 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 EXAMPLES
-------- --------
git-add Documentation/\\*.txt:: git-add Documentation/\\*.txt::
Adds all `\*.txt` files that are not in the index under Adds content from all `\*.txt` files under `Documentation`
`Documentation` directory and its subdirectories. directory and its subdirectories.
+ +
Note that the asterisk `\*` is quoted from the shell in this Note that the asterisk `\*` is quoted from the shell in this
example; this lets the command to include the files from example; this lets the command to include the files from
@ -62,15 +62,18 @@ subdirectories of `Documentation/` directory.
git-add git-*.sh:: 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 Because this example lets shell expand the asterisk
(i.e. you are listing the files explicitly), it does not (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 See Also
-------- --------
gitlink:git-status[1]
gitlink:git-rm[1] gitlink:git-rm[1]
gitlink:git-ls-files[1] gitlink:git-mv[1]
gitlink:git-commit[1]
gitlink:git-update-index[1]
Author Author
------ ------

217
Documentation/git-commit.txt
View File

@ -14,25 +14,41 @@ SYNOPSIS
DESCRIPTION DESCRIPTION
----------- -----------
Updates the index file for given paths, or all modified files if Use 'git commit' when you want to record your changes into the repository
'-a' is specified, and makes a commit object. The command specified along with a log message describing what the commit is about. All changes
by either the VISUAL or EDITOR environment variables are used to edit to be committed must be explicitly identified using one of the following
the commit log message. methods:
Several environment variable are used during commits. They are 1. by using gitlink:git-add[1] to incrementally "add" changes to the
documented in gitlink:git-commit-tree[1]. 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 OPTIONS
------- -------
-a|--all:: -a|--all::
Update all paths in the index file. This flag notices Tell the command to automatically stage files that have
files that have been modified and deleted, but new files been modified and deleted, but new files you have not
you have not told git about are not affected. told git about are not affected.
-c or -C <commit>:: -c or -C <commit>::
Take existing commit object, and reuse the log message Take existing commit object, and reuse the log message
@ -55,16 +71,13 @@ OPTIONS
-s|--signoff:: -s|--signoff::
Add Signed-off-by line at the end of the commit message. Add Signed-off-by line at the end of the commit message.
-v|--verify:: --no-verify::
Look for suspicious lines the commit introduces, and By default, the command looks for suspicious lines the
abort committing if there is one. The definition of commit introduces, and aborts committing if there is one.
'suspicious lines' is currently the lines that has The definition of 'suspicious lines' is currently the
trailing whitespaces, and the lines whose indentation lines that has trailing whitespaces, and the lines whose
has a SP character immediately followed by a TAB indentation has a SP character immediately followed by a
character. This is the default. TAB character. This option turns off the check.
-n|--no-verify::
The opposite of `--verify`.
-e|--edit:: -e|--edit::
The message taken from file with `-F`, command line with 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:: -i|--include::
Instead of committing only the files specified on the Before making a commit out of staged contents so far,
command line, update them in the index file and then stage the contents of paths given on the command line
commit the whole index. This is the traditional as well. This is usually not what you want unless you
behavior. are concluding a conflicted merge.
-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.
\--:: \--::
Do not interpret any more arguments as options. Do not interpret any more arguments as options.
<file>...:: <file>...::
Files to be committed. The meaning of these is When files are given on the command line, the command
different between `--include` and `--only`. Without commits the contents of the named files, without
either, it defaults `--only` semantics. recording the changes already staged. The contents of
these files are also staged for the next commit on top
If you make a commit and then found a mistake immediately after of what have been staged before.
that, you can recover from it with gitlink:git-reset[1].
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 $ edit hello.c
even the command is invoked from a subdirectory. $ 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... Instead of staging files after each individual change, you can
git commit 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 The command `git commit -a` first looks at your working tree,
commits only the changes made to the specified paths. It has notices that you have modified hello.c and removed goodbye.c,
however several safety valves to prevent confusion. and performs necessary `git add` and `git rm` for you.
. It refuses to run during a merge (i.e. when After staging changes to many files, you can alter the order the
`$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users changes are recorded in, by giving pathnames to `git commit`.
that the traditional semantics now needs -i flag. 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. $ edit hello.c hello.h
This is because an earlier `git diff` (not `git diff HEAD`) $ git add hello.c hello.h
would have shown the differences since the last `git $ edit Makefile
update-index paths...` to the user, and an inexperienced user $ git commit Makefile
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.
. It reads HEAD commit into a temporary index file, updates the This makes a commit that records the modification to `Makefile`.
specified `paths...` and makes a commit. At the same time, The changes staged for `hello.c` and `hello.h` are not included
the real index file is also updated with the same `paths...`. 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 $ git commit
which subdirectory the command is invoked in. ------------
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 Author
------ ------

46
Documentation/tutorial.txt
View File

@ -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 example, use the first line on the Subject line and the rest of the
commit in the body. commit in the body.
To add a new file, first create the file, then
------------------------------------------------ Git tracks content not files
$ git add path/to/new/file ----------------------------
------------------------------------------------
then commit as usual. No special command is required when removing a With git you have to explicitly "add" all the changed _content_ you
file; just remove it, then tell `commit` about the file as usual. 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 At any point you can view the history of your changes using

6
builtin-add.c
View File

@ -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); 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++) { for (i = 1; i < argc; i++) {
const char *arg = argv[i]; const char *arg = argv[i];
@ -131,6 +128,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)
return 0; return 0;
} }
if (read_cache() < 0)
die("index file corrupt");
for (i = 0; i < dir.nr; i++) for (i = 0; i < dir.nr; i++)
add_file_to_index(dir.entries[i]->name, verbose); add_file_to_index(dir.entries[i]->name, verbose);

12
git-commit.sh
View File

@ -350,19 +350,9 @@ t,)
refuse_partial "Cannot do a partial commit during a merge." refuse_partial "Cannot do a partial commit during a merge."
fi fi
TMP_INDEX="$GIT_DIR/tmp-index$$" 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 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. # the same way.
if test -z "$initial_commit" if test -z "$initial_commit"
then then

2
wt-status.c
View File

@ -163,7 +163,7 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
int i; int i;
if (q->nr) if (q->nr)
wt_status_print_header("Changed but not updated", 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++) for (i = 0; i < q->nr; i++)
wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]); wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
if (q->nr) if (q->nr)