mirror/ git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-05-23 07:56:24 +02:00
Code
git/git-commit.sh

751 lines
16 KiB
Bash
Raw Normal View History

Add "commit" helper script This is meant to make raw git not hugely less usable than something like raw CVS. I want to make a 1.0 release of the plumbing, and the actual commit part was just too intimidating.
2005-05-30 21:51:00 +02:00
#!/bin/sh
[PATCH] git-commit-script: get commit message from an existing one. With -m flag specified, git-commit-script takes the commit message along with author information from an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 11:22:05 +02:00
#
# Copyright (c) 2005 Linus Torvalds
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
# Copyright (c) 2006 Junio C Hamano
git status: skip empty directories, and add -u to show all untracked files By default, we use --others --directory to show uninteresting directories (to get user's attention) without their contents (to unclutter output). Showing empty directories do not make sense, so pass --no-empty-directory when we do so. Giving -u (or --untracked) disables this uncluttering to let the user get all untracked files. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-22 23:02:06 +02:00
USAGE='[-a] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-u] [--amend] [-e] [--author <author>] [[-i | -o] <path>...]'
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
SUBDIRECTORY_OK=Yes
git-sh-setup: die if outside git repository. Now all the users of this script detect its exit status and die, complaining that it is outside git repository. So move the code that dies from all callers to git-sh-setup script. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-24 09:12:11 +01:00
. git-sh-setup
Add "git-sh-setup-script" for common git shell script setup It sets up the normal git environment variables and a few helper functions (currently just "die()"), and returns ok if it all looks like a git archive. So use it something like . git-sh-setup-script || die "Not a git archive" to make the rest of the git scripts more careful and readable.
2005-07-08 19:57:21 +02:00
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
git-rev-parse --verify HEAD >/dev/null 2>&1 || initial_commit=t
branch=$(GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD)
case "$0" in
*status)
status_only=t
unmerged_ok_if_status=--unmerged ;;
*commit)
status_only=
unmerged_ok_if_status= ;;
esac
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
refuse_partial () {
echo >&2 "$1"
echo >&2 "You might have meant to say 'git commit -i paths...', perhaps?"
exit 1
}
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
THIS_INDEX="$GIT_DIR/index"
NEXT_INDEX="$GIT_DIR/next-index$$"
rm -f "$NEXT_INDEX"
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
save_index () {
Racy GIT (part #3) Commit 29e4d3635709778bcc808dbad0477efad82f8d7e fixed the underlying update-index races but git-commit was not careful enough to preserve the index file timestamp when copying the index file. This caused t3402 test to occasionally fail. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-29 23:48:22 +02:00
cp -p "$THIS_INDEX" "$NEXT_INDEX"
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
}
report () {
header="#
# $1:
# ($2)
#
"
trailer=""
while read status name newname
do
printf '%s' "$header"
header=""
trailer="#
"
case "$status" in
M ) echo "# modified: $name";;
D*) echo "# deleted: $name";;
T ) echo "# typechange: $name";;
C*) echo "# copied: $name -> $newname";;
R*) echo "# renamed: $name -> $newname";;
A*) echo "# new file: $name";;
U ) echo "# unmerged: $name";;
esac
done
printf '%s' "$trailer"
[ "$header" ]
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
}
run_status () {
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
(
# We always show status for the whole tree.
cd "$TOP"
git-commit --amend The new flag is used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current branch. The commit you create replaces the current tip -- if it was a merge, it will have the parents of the current tip as parents -- so the current top commit is discarded. It is a rough equivalent for: $ git reset --soft HEAD^ $ ... do something else to come up with the right tree ... $ git commit -c ORIG_HEAD but can be used to amend a merge commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-03 06:04:05 +01:00
IS_INITIAL="$initial_commit"
REFERENCE=HEAD
case "$amend" in
t)
# If we are amending the initial commit, there
# is no HEAD^1.
if git-rev-parse --verify "HEAD^1" >/dev/null 2>&1
then
REFERENCE="HEAD^1"
IS_INITIAL=
else
IS_INITIAL=t
fi
;;
esac
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
# If TMP_INDEX is defined, that means we are doing
# "--only" partial commit, and that index file is used
# to build the tree for the commit. Otherwise, if
# NEXT_INDEX exists, that is the index file used to
# make the commit. Otherwise we are using as-is commit
# so the regular index file is what we use to compare.
if test '' != "$TMP_INDEX"
then
GIT_INDEX_FILE="$TMP_INDEX"
export GIT_INDEX_FILE
elif test -f "$NEXT_INDEX"
then
GIT_INDEX_FILE="$NEXT_INDEX"
export GIT_INDEX_FILE
fi
case "$branch" in
refs/heads/master) ;;
*) echo "# On branch $branch" ;;
esac
git-commit --amend The new flag is used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current branch. The commit you create replaces the current tip -- if it was a merge, it will have the parents of the current tip as parents -- so the current top commit is discarded. It is a rough equivalent for: $ git reset --soft HEAD^ $ ... do something else to come up with the right tree ... $ git commit -c ORIG_HEAD but can be used to amend a merge commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-03 06:04:05 +01:00
if test -z "$IS_INITIAL"
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
then
git-commit -v: have patch at the end. It was pointed out that otherwise more important summary information prefixed with '#' would become prone to be missed. Also instead of chopping at the first '^---$' line, stop at the first 'diff --git a/' line. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-11 03:38:24 +01:00
git-diff-index -M --cached --name-status \
git-commit --amend The new flag is used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current branch. The commit you create replaces the current tip -- if it was a merge, it will have the parents of the current tip as parents -- so the current top commit is discarded. It is a rough equivalent for: $ git reset --soft HEAD^ $ ... do something else to come up with the right tree ... $ git commit -c ORIG_HEAD but can be used to amend a merge commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-03 06:04:05 +01:00
--diff-filter=MDTCRA $REFERENCE |
git-commit -v: have patch at the end. It was pointed out that otherwise more important summary information prefixed with '#' would become prone to be missed. Also instead of chopping at the first '^---$' line, stop at the first 'diff --git a/' line. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-11 03:38:24 +01:00
sed -e '
s/\\/\\\\/g
s/ /\\ /g
' |
report "Updated but not checked in" "will commit"
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
committable="$?"
else
echo '#
# Initial commit
#'
git-ls-files |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
s/^/A /
' |
report "Updated but not checked in" "will commit"
committable="$?"
fi
git-diff-files --name-status |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
' |
report "Changed but not updated" \
"use git-update-index to mark for commit"
git status: skip empty directories, and add -u to show all untracked files By default, we use --others --directory to show uninteresting directories (to get user's attention) without their contents (to unclutter output). Showing empty directories do not make sense, so pass --no-empty-directory when we do so. Giving -u (or --untracked) disables this uncluttering to let the user get all untracked files. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-22 23:02:06 +02:00
option=""
if test -z "$untracked_files"; then
option="--directory --no-empty-directory"
fi
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
if test -f "$GIT_DIR/info/exclude"
then
git status: skip empty directories, and add -u to show all untracked files By default, we use --others --directory to show uninteresting directories (to get user's attention) without their contents (to unclutter output). Showing empty directories do not make sense, so pass --no-empty-directory when we do so. Giving -u (or --untracked) disables this uncluttering to let the user get all untracked files. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-22 23:02:06 +02:00
git-ls-files -z --others $option \
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
--exclude-from="$GIT_DIR/info/exclude" \
--exclude-per-directory=.gitignore
else
git status: skip empty directories, and add -u to show all untracked files By default, we use --others --directory to show uninteresting directories (to get user's attention) without their contents (to unclutter output). Showing empty directories do not make sense, so pass --no-empty-directory when we do so. Giving -u (or --untracked) disables this uncluttering to let the user get all untracked files. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-22 23:02:06 +02:00
git-ls-files -z --others $option \
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
--exclude-per-directory=.gitignore
fi |
Using 'perl' in *.sh Some GIT's shell script are using bare 'perl' for perl invocation. Use @@PERL@@ symbol and replace it with PERL_PATH_SQ everywhere. Signed-off-by: Michal Rokos <michal.rokos@nextsoft.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-08 17:32:04 +02:00
@@PERL@@ -e '$/ = "\0";
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
my $shown = 0;
while (<>) {
chomp;
s|\\|\\\\|g;
s|\t|\\t|g;
s|\n|\\n|g;
s/^/# /;
if (!$shown) {
print "#\n# Untracked files:\n";
print "# (use \"git add\" to add to commit)\n";
print "#\n";
$shown = 1;
}
print "$_\n";
}
'
git-commit -v: have patch at the end. It was pointed out that otherwise more important summary information prefixed with '#' would become prone to be missed. Also instead of chopping at the first '^---$' line, stop at the first 'diff --git a/' line. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-11 03:38:24 +01:00
Be verbose when !initial commit verbose option in git-commit.sh lead us to run git-diff-index, which needs a commit-ish we are making diff against. When we are commiting the fist set, we obviously don't have any commit-ish in the repo. So we just skip the git-diff-index run. It might be possible to produce diff against empty but do we need that? Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-20 14:11:12 +01:00
if test -n "$verbose" -a -z "$IS_INITIAL"
git-commit -v: have patch at the end. It was pointed out that otherwise more important summary information prefixed with '#' would become prone to be missed. Also instead of chopping at the first '^---$' line, stop at the first 'diff --git a/' line. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-11 03:38:24 +01:00
then
git-commit --amend The new flag is used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current branch. The commit you create replaces the current tip -- if it was a merge, it will have the parents of the current tip as parents -- so the current top commit is discarded. It is a rough equivalent for: $ git reset --soft HEAD^ $ ... do something else to come up with the right tree ... $ git commit -c ORIG_HEAD but can be used to amend a merge commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-03 06:04:05 +01:00
git-diff-index --cached -M -p --diff-filter=MDTCRA $REFERENCE
git-commit -v: have patch at the end. It was pointed out that otherwise more important summary information prefixed with '#' would become prone to be missed. Also instead of chopping at the first '^---$' line, stop at the first 'diff --git a/' line. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-11 03:38:24 +01:00
fi
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
case "$committable" in
0)
git-commit --amend: two fixes. When running "git commit --amend" only to fix the commit log message without any content change, we mistakenly showed the git-status output that says "nothing to commit" without commenting it out. If you have already run update-index but you want to amend the top commit, "git commit --amend --only" without any paths should have worked, because --only means "starting from the base commit, update-index these paths only to prepare the index to commit, and perform the commit". However, we refused -o without paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-20 10:20:56 +02:00
case "$amend" in
t)
echo "# No changes" ;;
*)
echo "nothing to commit" ;;
esac
exit 1 ;;
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
esac
exit 0
)
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
}
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
trap '
test -z "$TMP_INDEX" || {
test -f "$TMP_INDEX" && rm -f "$TMP_INDEX"
}
rm -f "$NEXT_INDEX"
' 0
################################################################
# Command line argument parsing and sanity checking
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
all=
also=
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
only=
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
logfile=
use_commit=
git-commit --amend The new flag is used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current branch. The commit you create replaces the current tip -- if it was a merge, it will have the parents of the current tip as parents -- so the current top commit is discarded. It is a rough equivalent for: $ git reset --soft HEAD^ $ ... do something else to come up with the right tree ... $ git commit -c ORIG_HEAD but can be used to amend a merge commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-03 06:04:05 +01:00
amend=
git-commit: allow -e option anywhere on command line Previously, the command 'git-commit -e -m foo' would ignore the '-e' option because the '-m' option overwrites the no_edit flag during sequential option parsing. Now we cause -e to reset the no_edit flag after all options are parsed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-23 15:43:38 +02:00
edit_flag=
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
no_edit=
log_given=
log_message=
verify=t
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
verbose=
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
signoff=
force_author=
commit: detect misspelled pathspec while making a partial commit. When you say "git commit Documentaiton" to make partial commit for the files only in that directory, we did not detect that as a misspelled pathname and attempted to commit index without change. If nothing matched, there is no harm done, but if the index gets modified otherwise by having another valid pathspec or after an explicit update-index, a user will not notice without paying attention to the "git status" preview. This introduces --error-unmatch option to ls-files, and uses it to detect this common user error. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-14 21:40:20 +01:00
only_include_assumed=
git status: skip empty directories, and add -u to show all untracked files By default, we use --others --directory to show uninteresting directories (to get user's attention) without their contents (to unclutter output). Showing empty directories do not make sense, so pass --no-empty-directory when we do so. Giving -u (or --untracked) disables this uncluttering to let the user get all untracked files. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-22 23:02:06 +02:00
untracked_files=
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
while case "$#" in 0) break;; esac
[PATCH] git-commit-script: get commit message from an existing one. With -m flag specified, git-commit-script takes the commit message along with author information from an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 11:22:05 +02:00
do
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
case "$1" in
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
-F|--F|-f|--f|--fi|--fil|--file)
case "$#" in 1) usage ;; esac
shift
no_edit=t
log_given=t$log_given
logfile="$1"
shift
;;
-F*|-f*)
no_edit=t
log_given=t$log_given
Fix expr usage for FreeBSD Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27 18:54:26 +02:00
logfile=`expr "z$1" : 'z-[Ff]\(.*\)'`
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
shift
;;
--F=*|--f=*|--fi=*|--fil=*|--file=*)
no_edit=t
log_given=t$log_given
Fix expr usage for FreeBSD Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27 18:54:26 +02:00
logfile=`expr "z$1" : 'z-[^=]*=\(.*\)'`
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
shift
;;
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
-a|--a|--al|--all)
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
all=t
shift
;;
--au=*|--aut=*|--auth=*|--autho=*|--author=*)
Fix expr usage for FreeBSD Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27 18:54:26 +02:00
force_author=`expr "z$1" : 'z-[^=]*=\(.*\)'`
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
shift
;;
--au|--aut|--auth|--autho|--author)
case "$#" in 1) usage ;; esac
shift
force_author="$1"
shift
;;
-e|--e|--ed|--edi|--edit)
git-commit: allow -e option anywhere on command line Previously, the command 'git-commit -e -m foo' would ignore the '-e' option because the '-m' option overwrites the no_edit flag during sequential option parsing. Now we cause -e to reset the no_edit flag after all options are parsed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-23 15:43:38 +02:00
edit_flag=t
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
shift
;;
-i|--i|--in|--inc|--incl|--inclu|--includ|--include)
also=t
shift
;;
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
-o|--o|--on|--onl|--only)
only=t
shift
;;
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
-m|--m|--me|--mes|--mess|--messa|--messag|--message)
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
case "$#" in 1) usage ;; esac
shift
Allow multiple -m options to git-commit. I find it very convenient to be able to supply multiple paragraphs of text on the command line with a single git-commit call. This change permits multiple -m/--message type options to be supplied to git-commit with each message being added as its own paragraph of text in the commit message. The -m option is still not permitted with -c/-C/-F nor are multiple occurrences of these options permitted. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-29 10:45:49 +02:00
log_given=m$log_given
if test "$log_message" = ''
then
log_message="$1"
else
log_message="$log_message
$1"
fi
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
no_edit=t
shift
;;
-m*)
Allow multiple -m options to git-commit. I find it very convenient to be able to supply multiple paragraphs of text on the command line with a single git-commit call. This change permits multiple -m/--message type options to be supplied to git-commit with each message being added as its own paragraph of text in the commit message. The -m option is still not permitted with -c/-C/-F nor are multiple occurrences of these options permitted. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-29 10:45:49 +02:00
log_given=m$log_given
if test "$log_message" = ''
then
Fix expr usage for FreeBSD Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27 18:54:26 +02:00
log_message=`expr "z$1" : 'z-m\(.*\)'`
Allow multiple -m options to git-commit. I find it very convenient to be able to supply multiple paragraphs of text on the command line with a single git-commit call. This change permits multiple -m/--message type options to be supplied to git-commit with each message being added as its own paragraph of text in the commit message. The -m option is still not permitted with -c/-C/-F nor are multiple occurrences of these options permitted. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-29 10:45:49 +02:00
else
log_message="$log_message
Fix expr usage for FreeBSD Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27 18:54:26 +02:00
`expr "z$1" : 'z-m\(.*\)'`"
Allow multiple -m options to git-commit. I find it very convenient to be able to supply multiple paragraphs of text on the command line with a single git-commit call. This change permits multiple -m/--message type options to be supplied to git-commit with each message being added as its own paragraph of text in the commit message. The -m option is still not permitted with -c/-C/-F nor are multiple occurrences of these options permitted. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-29 10:45:49 +02:00
fi
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
no_edit=t
shift
;;
--m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)
Allow multiple -m options to git-commit. I find it very convenient to be able to supply multiple paragraphs of text on the command line with a single git-commit call. This change permits multiple -m/--message type options to be supplied to git-commit with each message being added as its own paragraph of text in the commit message. The -m option is still not permitted with -c/-C/-F nor are multiple occurrences of these options permitted. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-29 10:45:49 +02:00
log_given=m$log_given
if test "$log_message" = ''
then
Fix expr usage for FreeBSD Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27 18:54:26 +02:00
log_message=`expr "z$1" : 'z-[^=]*=\(.*\)'`
Allow multiple -m options to git-commit. I find it very convenient to be able to supply multiple paragraphs of text on the command line with a single git-commit call. This change permits multiple -m/--message type options to be supplied to git-commit with each message being added as its own paragraph of text in the commit message. The -m option is still not permitted with -c/-C/-F nor are multiple occurrences of these options permitted. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-29 10:45:49 +02:00
else
log_message="$log_message
Fix expr usage for FreeBSD Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27 18:54:26 +02:00
`expr "z$1" : 'zq-[^=]*=\(.*\)'`"
Allow multiple -m options to git-commit. I find it very convenient to be able to supply multiple paragraphs of text on the command line with a single git-commit call. This change permits multiple -m/--message type options to be supplied to git-commit with each message being added as its own paragraph of text in the commit message. The -m option is still not permitted with -c/-C/-F nor are multiple occurrences of these options permitted. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-29 10:45:49 +02:00
fi
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
no_edit=t
shift
;;
-n|--n|--no|--no-|--no-v|--no-ve|--no-ver|--no-veri|--no-verif|--no-verify)
verify=
shift
;;
git-commit --amend The new flag is used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current branch. The commit you create replaces the current tip -- if it was a merge, it will have the parents of the current tip as parents -- so the current top commit is discarded. It is a rough equivalent for: $ git reset --soft HEAD^ $ ... do something else to come up with the right tree ... $ git commit -c ORIG_HEAD but can be used to amend a merge commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-03 06:04:05 +01:00
--a|--am|--ame|--amen|--amend)
amend=t
log_given=t$log_given
use_commit=HEAD
shift
;;
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
-c)
case "$#" in 1) usage ;; esac
shift
log_given=t$log_given
use_commit="$1"
no_edit=
shift
;;
--ree=*|--reed=*|--reedi=*|--reedit=*|--reedit-=*|--reedit-m=*|\
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
--reedit-me=*|--reedit-mes=*|--reedit-mess=*|--reedit-messa=*|\
--reedit-messag=*|--reedit-message=*)
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
log_given=t$log_given
Fix expr usage for FreeBSD Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27 18:54:26 +02:00
use_commit=`expr "z$1" : 'z-[^=]*=\(.*\)'`
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
no_edit=
shift
;;
--ree|--reed|--reedi|--reedit|--reedit-|--reedit-m|--reedit-me|\
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
--reedit-mes|--reedit-mess|--reedit-messa|--reedit-messag|--reedit-message)
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
case "$#" in 1) usage ;; esac
shift
log_given=t$log_given
use_commit="$1"
no_edit=
shift
;;
-C)
case "$#" in 1) usage ;; esac
shift
log_given=t$log_given
use_commit="$1"
no_edit=t
shift
;;
--reu=*|--reus=*|--reuse=*|--reuse-=*|--reuse-m=*|--reuse-me=*|\
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
--reuse-mes=*|--reuse-mess=*|--reuse-messa=*|--reuse-messag=*|\
--reuse-message=*)
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
log_given=t$log_given
Fix expr usage for FreeBSD Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27 18:54:26 +02:00
use_commit=`expr "z$1" : 'z-[^=]*=\(.*\)'`
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
no_edit=t
shift
;;
--reu|--reus|--reuse|--reuse-|--reuse-m|--reuse-me|--reuse-mes|\
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
--reuse-mess|--reuse-messa|--reuse-messag|--reuse-message)
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
case "$#" in 1) usage ;; esac
shift
log_given=t$log_given
use_commit="$1"
no_edit=t
shift
;;
Add --signoff and --verify option to git commit. As brought up in the discussion which followed a patch to add a signed-off-by line with the --sign flag to format-patch from Johannes Schindelin, add --signoff to the git commit command. Also add --verify to make sure the lines you introduced are clean, which is more useful in commit but not very much in format-patch as it was originally implemented, because finding botches at format-patch time is too late. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-13 08:39:15 +02:00
-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
signoff=t
shift
;;
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
verbose=t
shift
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
;;
git status: skip empty directories, and add -u to show all untracked files By default, we use --others --directory to show uninteresting directories (to get user's attention) without their contents (to unclutter output). Showing empty directories do not make sense, so pass --no-empty-directory when we do so. Giving -u (or --untracked) disables this uncluttering to let the user get all untracked files. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-22 23:02:06 +02:00
-u|--u|--un|--unt|--untr|--untra|--untrac|--untrack|--untracke|--untracked|\
--untracked-|--untracked-f|--untracked-fi|--untracked-fil|--untracked-file|\
--untracked-files)
untracked_files=t
shift
;;
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
--)
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
shift
break
;;
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
-*)
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
usage
;;
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
*)
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
break
;;
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
esac
[PATCH] git-commit-script: get commit message from an existing one. With -m flag specified, git-commit-script takes the commit message along with author information from an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 11:22:05 +02:00
done
git-commit: allow -e option anywhere on command line Previously, the command 'git-commit -e -m foo' would ignore the '-e' option because the '-m' option overwrites the no_edit flag during sequential option parsing. Now we cause -e to reset the no_edit flag after all options are parsed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-23 15:43:38 +02:00
case "$edit_flag" in t) no_edit= ;; esac
[PATCH] git-commit-script: get commit message from an existing one. With -m flag specified, git-commit-script takes the commit message along with author information from an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 11:22:05 +02:00
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
################################################################
# Sanity check options
git-commit --amend The new flag is used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current branch. The commit you create replaces the current tip -- if it was a merge, it will have the parents of the current tip as parents -- so the current top commit is discarded. It is a rough equivalent for: $ git reset --soft HEAD^ $ ... do something else to come up with the right tree ... $ git commit -c ORIG_HEAD but can be used to amend a merge commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-03 06:04:05 +01:00
case "$amend,$initial_commit" in
t,t)
die "You do not have anything to amend." ;;
t,)
if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
die "You are in the middle of a merge -- cannot amend."
fi ;;
esac
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
case "$log_given" in
tt*)
Allow multiple -m options to git-commit. I find it very convenient to be able to supply multiple paragraphs of text on the command line with a single git-commit call. This change permits multiple -m/--message type options to be supplied to git-commit with each message being added as its own paragraph of text in the commit message. The -m option is still not permitted with -c/-C/-F nor are multiple occurrences of these options permitted. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-29 10:45:49 +02:00
die "Only one of -c/-C/-F can be used." ;;
*tm*|*mt*)
die "Option -m cannot be combined with -c/-C/-F." ;;
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
esac
git-commit --amend: two fixes. When running "git commit --amend" only to fix the commit log message without any content change, we mistakenly showed the git-status output that says "nothing to commit" without commenting it out. If you have already run update-index but you want to amend the top commit, "git commit --amend --only" without any paths should have worked, because --only means "starting from the base commit, update-index these paths only to prepare the index to commit, and perform the commit". However, we refused -o without paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-20 10:20:56 +02:00
case "$#,$also,$only,$amend" in
*,t,t,*)
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
die "Only one of --include/--only can be used." ;;
git-commit --amend: two fixes. When running "git commit --amend" only to fix the commit log message without any content change, we mistakenly showed the git-status output that says "nothing to commit" without commenting it out. If you have already run update-index but you want to amend the top commit, "git commit --amend --only" without any paths should have worked, because --only means "starting from the base commit, update-index these paths only to prepare the index to commit, and perform the commit". However, we refused -o without paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-20 10:20:56 +02:00
0,t,,* | 0,,t,)
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
die "No paths with --include/--only does not make sense." ;;
git-commit --amend: two fixes. When running "git commit --amend" only to fix the commit log message without any content change, we mistakenly showed the git-status output that says "nothing to commit" without commenting it out. If you have already run update-index but you want to amend the top commit, "git commit --amend --only" without any paths should have worked, because --only means "starting from the base commit, update-index these paths only to prepare the index to commit, and perform the commit". However, we refused -o without paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-20 10:20:56 +02:00
0,,t,t)
only_include_assumed="# Clever... amending the last one with dirty index." ;;
0,,,*)
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
;;
git-commit --amend: two fixes. When running "git commit --amend" only to fix the commit log message without any content change, we mistakenly showed the git-status output that says "nothing to commit" without commenting it out. If you have already run update-index but you want to amend the top commit, "git commit --amend --only" without any paths should have worked, because --only means "starting from the base commit, update-index these paths only to prepare the index to commit, and perform the commit". However, we refused -o without paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-20 10:20:56 +02:00
*,,,*)
Merge branch 'jc/commit' * jc/commit: commit: detect misspelled pathspec while making a partial commit. combine-diff: diff-files fix (#2) combine-diff: diff-files fix.
2006-02-15 02:51:02 +01:00
only_include_assumed="# Explicit paths specified without -i nor -o; assuming --only paths..."
git-commit: Now --only semantics is the default. This changes the "git commit paths..." to default to --only semantics from traditional --include semantics, as agreed on the list. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-13 08:55:07 +01:00
also=
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
;;
esac
unset only
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
case "$all,$also,$#" in
t,t,*)
die "Cannot use -a and -i at the same time." ;;
t,,[1-9]*)
die "Paths with -a does not make sense." ;;
,t,0)
die "No paths with -i does not make sense." ;;
esac
################################################################
# Prepare index to have a tree to be committed
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
TOP=`git-rev-parse --show-cdup`
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
if test -z "$TOP"
then
TOP=./
fi
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
case "$all,$also" in
t,)
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
save_index &&
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
(
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
cd "$TOP"
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
GIT_INDEX_FILE="$NEXT_INDEX"
export GIT_INDEX_FILE
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
git-diff-files --name-only -z |
git-update-index --remove -z --stdin
)
Fix git-commit without paths. The earlier one to grab output from diff-files --name-only has a grave bug that when no paths are given it ended up doing the equivalent of "git-commit --all", which was not what I intended. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-18 00:17:03 +02:00
;;
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
,t)
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
save_index &&
commit: detect misspelled pathspec while making a partial commit. When you say "git commit Documentaiton" to make partial commit for the files only in that directory, we did not detect that as a misspelled pathname and attempted to commit index without change. If nothing matched, there is no harm done, but if the index gets modified otherwise by having another valid pathspec or after an explicit update-index, a user will not notice without paying attention to the "git status" preview. This introduces --error-unmatch option to ls-files, and uses it to detect this common user error. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-14 21:40:20 +01:00
git-ls-files --error-unmatch -- "$@" >/dev/null || exit
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
git-diff-files --name-only -z -- "$@" |
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
(
cd "$TOP"
GIT_INDEX_FILE="$NEXT_INDEX"
export GIT_INDEX_FILE
git-update-index --remove -z --stdin
)
git-commit: pass explicit path to git-diff-files. When running "git commit" with explicit path arguments, allow it to take directory name. This makes "git commit Documentation/" to commit everything that is changed under Documentation/ directory. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-17 03:08:19 +02:00
;;
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
,)
case "$#" in
0)
;; # commit as-is
*)
if test -f "$GIT_DIR/MERGE_HEAD"
then
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 \
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
--diff-filter=DMTU HEAD -- "$@"`
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
test -z "$dirty_in_index" ||
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
refuse_partial "Different in index and the last commit:
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
$dirty_in_index"
fi
commit: detect misspelled pathspec while making a partial commit. When you say "git commit Documentaiton" to make partial commit for the files only in that directory, we did not detect that as a misspelled pathname and attempted to commit index without change. If nothing matched, there is no harm done, but if the index gets modified otherwise by having another valid pathspec or after an explicit update-index, a user will not notice without paying attention to the "git status" preview. This introduces --error-unmatch option to ls-files, and uses it to detect this common user error. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-14 21:40:20 +01:00
commit_only=`git-ls-files --error-unmatch -- "$@"` || exit
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
# Build the temporary index and update the real index
# the same way.
if test -z "$initial_commit"
then
cp "$THIS_INDEX" "$TMP_INDEX"
GIT_INDEX_FILE="$TMP_INDEX" git-read-tree -m HEAD
else
rm -f "$TMP_INDEX"
fi || exit
echo "$commit_only" |
GIT_INDEX_FILE="$TMP_INDEX" \
git-update-index --add --remove --stdin &&
save_index &&
echo "$commit_only" |
(
GIT_INDEX_FILE="$NEXT_INDEX"
export GIT_INDEX_FILE
git-update-index --remove --stdin
) || exit
;;
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
esac
;;
esac
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
################################################################
# If we do as-is commit, the index file will be THIS_INDEX,
# otherwise NEXT_INDEX after we make this commit. We leave
# the index as is if we abort.
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
if test -f "$NEXT_INDEX"
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
then
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
USE_INDEX="$NEXT_INDEX"
else
USE_INDEX="$THIS_INDEX"
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
fi
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
GIT_INDEX_FILE="$USE_INDEX" \
git-update-index -q $unmerged_ok_if_status --refresh || exit
################################################################
# If the request is status, just show it and exit.
case "$0" in
*status)
run_status
exit $?
esac
################################################################
# Grab commit message, write out tree and make commit.
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
if test t = "$verify" && test -x "$GIT_DIR"/hooks/pre-commit
then
if test "$TMP_INDEX"
then
GIT_INDEX_FILE="$TMP_INDEX" "$GIT_DIR"/hooks/pre-commit
else
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
GIT_INDEX_FILE="$USE_INDEX" "$GIT_DIR"/hooks/pre-commit
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
fi || exit
fi
Add --signoff and --verify option to git commit. As brought up in the discussion which followed a patch to add a signed-off-by line with the --sign flag to format-patch from Johannes Schindelin, add --signoff to the git commit command. Also add --verify to make sure the lines you introduced are clean, which is more useful in commit but not very much in format-patch as it was originally implemented, because finding botches at format-patch time is too late. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-13 08:39:15 +02:00
Accept -m and friends for initial commits and merge commits. Yes it was irritating not to be able to do so. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26 03:57:35 +02:00
if test "$log_message" != ''
then
echo "$log_message"
elif test "$logfile" != ""
then
if test "$logfile" = -
then
test -t 0 &&
echo >&2 "(reading log message from standard input)"
cat
else
cat <"$logfile"
fi
elif test "$use_commit" != ""
then
git-cat-file commit "$use_commit" | sed -e '1,/^$/d'
Do not put automatic merge message after signed-off-by line. 'git-commit -s' after a failed automerge inserted the automerge message in a wrong place. The signed-off-by line should come last. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-02 07:01:28 +01:00
elif test -f "$GIT_DIR/MERGE_HEAD" && test -f "$GIT_DIR/MERGE_MSG"
then
cat "$GIT_DIR/MERGE_MSG"
git-merge --squash Some people tend to do many little commits on a topic branch, recording all the trials and errors, and when the topic is reasonably cooked well, would want to record the net effect of the series as one commit on top of the mainline, removing the cruft from the history. The topic is then abandoned or forked off again from that point at the mainline. The barebone porcelainish that comes with core git tools does not officially support such operation, but you can fake it by using "git pull --no-merge" when such a topic branch is not a strict superset of the mainline, like this: git checkout mainline git pull --no-commit . that-topic-branch : fix conflicts if any rm -f .git/MERGE_HEAD git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged This however does not work when the topic branch is a fast forward of the mainline, because normal "git pull" will never create a merge commit in such a case, and there is nothing special --no-commit could do to begin with. This patch introduces a new option, --squash, to support such a workflow officially in both fast-forward case and true merge case. The user-level operation would be the same in both cases: git checkout mainline git pull --squash . that-topic-branch : fix conflicts if any -- naturally, there would be : no conflict if fast forward. git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged When the current branch is already up-to-date with respect to the other branch, there truly is nothing to do, so the new option does not have any effect. This was brought up in #git IRC channel recently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-23 10:37:02 +02:00
elif test -f "$GIT_DIR/SQUASH_MSG"
then
cat "$GIT_DIR/SQUASH_MSG"
Write .editmsg in GIT_DIR to avoid being in git-status. It appears in the git-status output during a git-commit if you have something in info/exclude. Also for .cmitmsg and .cmitchk to make git-commit work in read-only working trees. [jc: while we are at it, I removed the use of .cmitchk temporary file which was not necessary, and renamed them -- they are out of way now and do not have to be dotfiles anymore.] Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10 02:30:19 +02:00
fi | git-stripspace >"$GIT_DIR"/COMMIT_EDITMSG
Use 'git status' now it can handle initial commit. Update 'git commit' to use the updated `git status`. Also earlier the `-s` flag was ignored for the initial commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-01 02:15:25 +02:00
case "$signoff" in
t)
Leave an empty line between log and sign-off. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-04 08:49:46 +02:00
{
echo
git-var GIT_COMMITTER_IDENT | sed -e '
s/>.*/>/
s/^/Signed-off-by: /
'
Write .editmsg in GIT_DIR to avoid being in git-status. It appears in the git-status output during a git-commit if you have something in info/exclude. Also for .cmitmsg and .cmitchk to make git-commit work in read-only working trees. [jc: while we are at it, I removed the use of .cmitchk temporary file which was not necessary, and renamed them -- they are out of way now and do not have to be dotfiles anymore.] Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10 02:30:19 +02:00
} >>"$GIT_DIR"/COMMIT_EDITMSG
Use 'git status' now it can handle initial commit. Update 'git commit' to use the updated `git status`. Also earlier the `-s` flag was ignored for the initial commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-01 02:15:25 +02:00
;;
esac
git-commit: do not muck with commit message when no_edit is set. Spotted by Linus and Darrin Thompson. When we took a commit message from -F <file> with an incomplete line, we appended "git status" output, which ended up attaching a lone "#" at the end. We still need the "do we have anything to commit?" check by running "status" (which has to know what to do in different cases with -i/-o/-a), but there is no point appending its output to the proposed commit message given by the user. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-12 20:45:18 +02:00
if test -f "$GIT_DIR/MERGE_HEAD" && test -z "$no_edit"; then
Use 'git status' now it can handle initial commit. Update 'git commit' to use the updated `git status`. Also earlier the `-s` flag was ignored for the initial commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-01 02:15:25 +02:00
echo "#"
trivial: typo in git-commit.sh Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-05 12:44:59 +01:00
echo "# It looks like you may be committing a MERGE."
Use 'git status' now it can handle initial commit. Update 'git commit' to use the updated `git status`. Also earlier the `-s` flag was ignored for the initial commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-01 02:15:25 +02:00
echo "# If this is not correct, please remove the file"
echo "# $GIT_DIR/MERGE_HEAD"
echo "# and try again"
echo "#"
Write .editmsg in GIT_DIR to avoid being in git-status. It appears in the git-status output during a git-commit if you have something in info/exclude. Also for .cmitmsg and .cmitchk to make git-commit work in read-only working trees. [jc: while we are at it, I removed the use of .cmitchk temporary file which was not necessary, and renamed them -- they are out of way now and do not have to be dotfiles anymore.] Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10 02:30:19 +02:00
fi >>"$GIT_DIR"/COMMIT_EDITMSG
Accept -m and friends for initial commits and merge commits. Yes it was irritating not to be able to do so. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26 03:57:35 +02:00
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
# Author
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
if test '' != "$force_author"
then
Shell utilities: Guard against expr' magic tokens. Some words, e.g., `match', are special to expr(1), and cause strange parsing effects. Track down all uses of expr and mangle the arguments so that this isn't a problem. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-14 00:01:24 +02:00
GIT_AUTHOR_NAME=`expr "z$force_author" : 'z\(.*[^ ]\) *<.*'` &&
GIT_AUTHOR_EMAIL=`expr "z$force_author" : '.*\(<.*\)'` &&
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
test '' != "$GIT_AUTHOR_NAME" &&
test '' != "$GIT_AUTHOR_EMAIL" ||
Fix more typos, primarily in the code The only visible change is that git-blame doesn't understand "--compability" anymore, but it does accept "--compatibility" instead, which is already documented. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-10 07:50:18 +02:00
die "malformed --author parameter"
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
elif test '' != "$use_commit"
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
then
pick_author_script='
/^author /{
s/'\''/'\''\\'\'\''/g
h
s/^author \([^<]*\) <[^>]*> .*$/\1/
s/'\''/'\''\'\'\''/g
s/.*/GIT_AUTHOR_NAME='\''&'\''/p
g
s/^author [^<]* <\([^>]*\)> .*$/\1/
s/'\''/'\''\'\'\''/g
s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
g
s/^author [^<]* <[^>]*> \(.*\)$/\1/
s/'\''/'\''\'\'\''/g
s/.*/GIT_AUTHOR_DATE='\''&'\''/p
q
}
'
set_author_env=`git-cat-file commit "$use_commit" |
LANG=C LC_ALL=C sed -ne "$pick_author_script"`
eval "$set_author_env"
export GIT_AUTHOR_NAME
export GIT_AUTHOR_EMAIL
export GIT_AUTHOR_DATE
fi
Make "git commit" handle initial commits too No need to confuse ex-CVS users with a complex initial commit sequence.
2005-06-14 19:20:14 +02:00
PARENTS="-p HEAD"
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
if test -z "$initial_commit"
Add git-symbolic-ref This adds the counterpart of git-update-ref that lets you read and create "symbolic refs". By default it uses a symbolic link to represent ".git/HEAD -> refs/heads/master", but it can be compiled to use the textfile symbolic ref. The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah .git/HEAD' have been converted to use new git-symbolic-ref command, so that they can deal with either implementation. Signed-off-by: Junio C Hamano <junio@twinsun.com>
2005-09-30 23:26:57 +02:00
then
[PATCH] git-commit-script: get commit message from an existing one. With -m flag specified, git-commit-script takes the commit message along with author information from an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 11:22:05 +02:00
if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
Multi-backend merge driver. The new command 'git merge' takes the current head and one or more remote heads, with the commit log message for the automated case. If the heads being merged are simple fast-forwards, it acts the same way as the current 'git resolve'. Otherwise, it tries different merge strategies and takes the result from the one that succeeded auto-merging, if there is any. If no merge strategy succeeds auto-merging, their results are evaluated for number of paths needed for hand resolving, and the one with the least number of such paths is left in the working tree. The user is asked to resolve them by hand and make a commit manually. The calling convention from the 'git merge' driver to merge strategy programs is very simple: - A strategy program is to be called 'git-merge-<strategy>'. - They take input of this form: <common1> <common2> ... '--' <head> <remote1> <remote2>... That is, one or more the common ancestors, double dash, the current head, and one or more remote heads being merged into the current branch. - Before a strategy program is called, the working tree is matched to the current <head>. - The strategy program exits with status code 0 when it successfully auto-merges the given heads. It should do update-cache for all the merged paths when it does so -- the index file will be used to record the merge result as a commit by the driver. - The strategy program exits with status code 1 when it leaves conflicts behind. It should do update-cache for all the merged paths that it successfully auto-merged, and leave the cache entry in the index file as the same as <head> for paths it could not auto-merge, and leave its best-effort result with conflict markers in the working tree when it does so. - The strategy program exists with status code other than 0 or 1 if it does not handle the given merge at all. As examples, this commit comes with merge strategies based on 'git resolve' and 'git octopus'. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-08 22:47:12 +02:00
PARENTS="-p HEAD "`sed -e 's/^/-p /' "$GIT_DIR/MERGE_HEAD"`
git-commit --amend The new flag is used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current branch. The commit you create replaces the current tip -- if it was a merge, it will have the parents of the current tip as parents -- so the current top commit is discarded. It is a rough equivalent for: $ git reset --soft HEAD^ $ ... do something else to come up with the right tree ... $ git commit -c ORIG_HEAD but can be used to amend a merge commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-03 06:04:05 +01:00
elif test -n "$amend"; then
PARENTS=$(git-cat-file commit HEAD |
sed -n -e '/^$/q' -e 's/^parent /-p /p')
Accept -m and friends for initial commits and merge commits. Yes it was irritating not to be able to do so. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26 03:57:35 +02:00
fi
git-commit: make sure we protect against races. An earlier commit 8098a178b26dc7a158d129a092a5b78da6d12b72 accidentally lost race protection from git-commit command. This commit reinstates it. When something else updates HEAD pointer while you were editing your commit message, the command would notice and abort the commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-03 06:13:24 +01:00
current=$(git-rev-parse --verify HEAD)
Add git-symbolic-ref This adds the counterpart of git-update-ref that lets you read and create "symbolic refs". By default it uses a symbolic link to represent ".git/HEAD -> refs/heads/master", but it can be compiled to use the textfile symbolic ref. The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah .git/HEAD' have been converted to use new git-symbolic-ref command, so that they can deal with either implementation. Signed-off-by: Junio C Hamano <junio@twinsun.com>
2005-09-30 23:26:57 +02:00
else
if [ -z "$(git-ls-files)" ]; then
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
echo >&2 Nothing to commit
Add git-symbolic-ref This adds the counterpart of git-update-ref that lets you read and create "symbolic refs". By default it uses a symbolic link to represent ".git/HEAD -> refs/heads/master", but it can be compiled to use the textfile symbolic ref. The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah .git/HEAD' have been converted to use new git-symbolic-ref command, so that they can deal with either implementation. Signed-off-by: Junio C Hamano <junio@twinsun.com>
2005-09-30 23:26:57 +02:00
exit 1
fi
PARENTS=""
git-commit: make sure we protect against races. An earlier commit 8098a178b26dc7a158d129a092a5b78da6d12b72 accidentally lost race protection from git-commit command. This commit reinstates it. When something else updates HEAD pointer while you were editing your commit message, the command would notice and abort the commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-03 06:13:24 +01:00
current=
Make "git commit" handle initial commits too No need to confuse ex-CVS users with a complex initial commit sequence.
2005-06-14 19:20:14 +02:00
fi
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
git-commit: do not muck with commit message when no_edit is set. Spotted by Linus and Darrin Thompson. When we took a commit message from -F <file> with an incomplete line, we appended "git status" output, which ended up attaching a lone "#" at the end. We still need the "do we have anything to commit?" check by running "status" (which has to know what to do in different cases with -i/-o/-a), but there is no point appending its output to the proposed commit message given by the user. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-12 20:45:18 +02:00
if test -z "$no_edit"
then
{
Add instructions to commit template. New users can be irritated by the git status text in their editor. Let's give them a short help. Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-26 01:42:18 +02:00
echo ""
echo "# Please enter the commit message for your changes."
echo "# (Comment lines starting with '#' will not be included)"
git-commit: do not muck with commit message when no_edit is set. Spotted by Linus and Darrin Thompson. When we took a commit message from -F <file> with an incomplete line, we appended "git status" output, which ended up attaching a lone "#" at the end. We still need the "do we have anything to commit?" check by running "status" (which has to know what to do in different cases with -i/-o/-a), but there is no point appending its output to the proposed commit message given by the user. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-12 20:45:18 +02:00
test -z "$only_include_assumed" || echo "$only_include_assumed"
run_status
} >>"$GIT_DIR"/COMMIT_EDITMSG
else
# we need to check if there is anything to commit
run_status >/dev/null
fi
git-commit --amend: allow empty commit. When amending a commit only to update the commit log message, git-status would rightly say "Nothing to commit." Do not let this prevent commit to be made. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05 05:36:28 +01:00
if [ "$?" != "0" -a ! -f "$GIT_DIR/MERGE_HEAD" -a -z "$amend" ]
Add "commit" helper script This is meant to make raw git not hugely less usable than something like raw CVS. I want to make a 1.0 release of the plumbing, and the actual commit part was just too intimidating.
2005-05-30 21:51:00 +02:00
then
git-merge --squash Some people tend to do many little commits on a topic branch, recording all the trials and errors, and when the topic is reasonably cooked well, would want to record the net effect of the series as one commit on top of the mainline, removing the cruft from the history. The topic is then abandoned or forked off again from that point at the mainline. The barebone porcelainish that comes with core git tools does not officially support such operation, but you can fake it by using "git pull --no-merge" when such a topic branch is not a strict superset of the mainline, like this: git checkout mainline git pull --no-commit . that-topic-branch : fix conflicts if any rm -f .git/MERGE_HEAD git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged This however does not work when the topic branch is a fast forward of the mainline, because normal "git pull" will never create a merge commit in such a case, and there is nothing special --no-commit could do to begin with. This patch introduces a new option, --squash, to support such a workflow officially in both fast-forward case and true merge case. The user-level operation would be the same in both cases: git checkout mainline git pull --squash . that-topic-branch : fix conflicts if any -- naturally, there would be : no conflict if fast forward. git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged When the current branch is already up-to-date with respect to the other branch, there truly is nothing to do, so the new option does not have any effect. This was brought up in #git IRC channel recently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-23 10:37:02 +02:00
rm -f "$GIT_DIR/COMMIT_EDITMSG" "$GIT_DIR/SQUASH_MSG"
git-commit: finishing touches. Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 01:08:01 +01:00
run_status
Add "commit" helper script This is meant to make raw git not hugely less usable than something like raw CVS. I want to make a 1.0 release of the plumbing, and the actual commit part was just too intimidating.
2005-05-30 21:51:00 +02:00
exit 1
fi
git-commit: do not muck with commit message when no_edit is set. Spotted by Linus and Darrin Thompson. When we took a commit message from -F <file> with an incomplete line, we appended "git status" output, which ended up attaching a lone "#" at the end. We still need the "do we have anything to commit?" check by running "status" (which has to know what to do in different cases with -i/-o/-a), but there is no point appending its output to the proposed commit message given by the user. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-12 20:45:18 +02:00
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
case "$no_edit" in
[PATCH] git-commit-script: get commit message from an existing one. With -m flag specified, git-commit-script takes the commit message along with author information from an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 11:22:05 +02:00
'')
Do not fall back on vi on dumb terminals. When TERM is set to 'dumb', do not start vi to edit the commit log message. Suggested by Amos Waterland. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 07:10:32 +01:00
case "${VISUAL:-$EDITOR},$TERM" in
,dumb)
echo >&2 "Terminal is dumb but no VISUAL nor EDITOR defined."
echo >&2 "Please supply the commit log message using either"
echo >&2 "-m or -F option. A boilerplate log message has"
echo >&2 "been prepared in $GIT_DIR/COMMIT_EDITMSG"
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
exit 1
;;
Do not fall back on vi on dumb terminals. When TERM is set to 'dumb', do not start vi to edit the commit log message. Suggested by Amos Waterland. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 07:10:32 +01:00
esac
Ensure author & committer before asking for commit message. It's better to find out you need to fix your author and committer information before you enter a long commit message. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-14 05:09:32 +02:00
git-var GIT_AUTHOR_IDENT > /dev/null || die
git-var GIT_COMMITTER_IDENT > /dev/null || die
Write .editmsg in GIT_DIR to avoid being in git-status. It appears in the git-status output during a git-commit if you have something in info/exclude. Also for .cmitmsg and .cmitchk to make git-commit work in read-only working trees. [jc: while we are at it, I removed the use of .cmitchk temporary file which was not necessary, and renamed them -- they are out of way now and do not have to be dotfiles anymore.] Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10 02:30:19 +02:00
${VISUAL:-${EDITOR:-vi}} "$GIT_DIR/COMMIT_EDITMSG"
[PATCH] git-commit-script: get commit message from an existing one. With -m flag specified, git-commit-script takes the commit message along with author information from an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 11:22:05 +02:00
;;
esac
Add commit hook and make the verification customizable. There are three hooks: - 'pre-commit' is given an opportunity to inspect what is being committed, before we invoke the EDITOR for the commit message; - 'commit-msg' is invoked on the commit log message after the user prepares it; - 'post-commit' is run after a successful commit is made. The first two can interfere to stop the commit. The last one is for after-the-fact notification. The earlier built-in commit checker is now moved to pre-commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-19 02:20:08 +02:00
case "$verify" in
t)
if test -x "$GIT_DIR"/hooks/commit-msg
then
Write .editmsg in GIT_DIR to avoid being in git-status. It appears in the git-status output during a git-commit if you have something in info/exclude. Also for .cmitmsg and .cmitchk to make git-commit work in read-only working trees. [jc: while we are at it, I removed the use of .cmitchk temporary file which was not necessary, and renamed them -- they are out of way now and do not have to be dotfiles anymore.] Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10 02:30:19 +02:00
"$GIT_DIR"/hooks/commit-msg "$GIT_DIR"/COMMIT_EDITMSG || exit
Add commit hook and make the verification customizable. There are three hooks: - 'pre-commit' is given an opportunity to inspect what is being committed, before we invoke the EDITOR for the commit message; - 'commit-msg' is invoked on the commit log message after the user prepares it; - 'post-commit' is run after a successful commit is made. The first two can interfere to stop the commit. The last one is for after-the-fact notification. The earlier built-in commit checker is now moved to pre-commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-19 02:20:08 +02:00
fi
esac
git-commit: filter out log message lines only when editor was run. The current behaviour strips out lines starting with a # even when fed through stdin or -m. This is particularly bad when importing history from another SCM (tailor 0.9.23 uses git-commit). In the best cases all lines are stripped and the commit fails with a confusing "empty log message" error, but in many cases the commit is done, with loss of information. Note that it is quite peculiar to just have "#" handled as a leading comment char here. One commonly meet CVS: or CG: or STG: as prefixes, and using GIT: would be more robust as well as consistent with other commit tools. However, that would break any tool relying on the # (if any). Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24 00:04:05 +02:00
if test -z "$no_edit"
then
sed -e '
/^diff --git a\/.*/{
s///
q
}
/^#/d
' "$GIT_DIR"/COMMIT_EDITMSG
else
cat "$GIT_DIR"/COMMIT_EDITMSG
fi |
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
git-stripspace >"$GIT_DIR"/COMMIT_MSG
Write .editmsg in GIT_DIR to avoid being in git-status. It appears in the git-status output during a git-commit if you have something in info/exclude. Also for .cmitmsg and .cmitchk to make git-commit work in read-only working trees. [jc: while we are at it, I removed the use of .cmitchk temporary file which was not necessary, and renamed them -- they are out of way now and do not have to be dotfiles anymore.] Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10 02:30:19 +02:00
if cnt=`grep -v -i '^Signed-off-by' "$GIT_DIR"/COMMIT_MSG |
git-stripspace |
wc -l` &&
test 0 -lt $cnt
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
then
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
if test -z "$TMP_INDEX"
then
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
tree=$(GIT_INDEX_FILE="$USE_INDEX" git-write-tree)
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 09:07:44 +01:00
else
tree=$(GIT_INDEX_FILE="$TMP_INDEX" git-write-tree) &&
rm -f "$TMP_INDEX"
fi &&
Write .editmsg in GIT_DIR to avoid being in git-status. It appears in the git-status output during a git-commit if you have something in info/exclude. Also for .cmitmsg and .cmitchk to make git-commit work in read-only working trees. [jc: while we are at it, I removed the use of .cmitchk temporary file which was not necessary, and renamed them -- they are out of way now and do not have to be dotfiles anymore.] Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10 02:30:19 +02:00
commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
Include ref log detail in commit, reset, etc. When updating a ref at the direction of the user include a reason why head was changed as part of the ref log (assuming it was enabled). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-19 11:16:18 +02:00
rlogm=$(sed -e 1q "$GIT_DIR"/COMMIT_MSG) &&
git-update-ref -m "commit: $rlogm" HEAD $commit $current &&
git-status -v This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 09:45:59 +01:00
rm -f -- "$GIT_DIR/MERGE_HEAD" &&
if test -f "$NEXT_INDEX"
then
mv "$NEXT_INDEX" "$THIS_INDEX"
else
: ;# happy
fi
git-commit: log parameter updates. While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09 02:03:14 +02:00
else
echo >&2 "* no commit message? aborting commit."
false
fi
Make "git commit" clean up after itself Noted by Jeff.
2005-06-20 04:57:01 +02:00
ret="$?"
git-merge --squash Some people tend to do many little commits on a topic branch, recording all the trials and errors, and when the topic is reasonably cooked well, would want to record the net effect of the series as one commit on top of the mainline, removing the cruft from the history. The topic is then abandoned or forked off again from that point at the mainline. The barebone porcelainish that comes with core git tools does not officially support such operation, but you can fake it by using "git pull --no-merge" when such a topic branch is not a strict superset of the mainline, like this: git checkout mainline git pull --no-commit . that-topic-branch : fix conflicts if any rm -f .git/MERGE_HEAD git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged This however does not work when the topic branch is a fast forward of the mainline, because normal "git pull" will never create a merge commit in such a case, and there is nothing special --no-commit could do to begin with. This patch introduces a new option, --squash, to support such a workflow officially in both fast-forward case and true merge case. The user-level operation would be the same in both cases: git checkout mainline git pull --squash . that-topic-branch : fix conflicts if any -- naturally, there would be : no conflict if fast forward. git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged When the current branch is already up-to-date with respect to the other branch, there truly is nothing to do, so the new option does not have any effect. This was brought up in #git IRC channel recently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-23 10:37:02 +02:00
rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG" "$GIT_DIR/SQUASH_MSG"
Only call git-rerere if $GIT_DIR/rr-cache exists. Johannes noticed that git-rerere depends on Digest.pm, and if one does not use the command, one can live without it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-12 03:55:43 +01:00
if test -d "$GIT_DIR/rr-cache"
then
git-rerere
fi
Add commit hook and make the verification customizable. There are three hooks: - 'pre-commit' is given an opportunity to inspect what is being committed, before we invoke the EDITOR for the commit message; - 'commit-msg' is invoked on the commit log message after the user prepares it; - 'post-commit' is run after a successful commit is made. The first two can interfere to stop the commit. The last one is for after-the-fact notification. The earlier built-in commit checker is now moved to pre-commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-19 02:20:08 +02:00
if test -x "$GIT_DIR"/hooks/post-commit && test "$ret" = 0
then
"$GIT_DIR"/hooks/post-commit
fi
Make "git commit" clean up after itself Noted by Jeff.
2005-06-20 04:57:01 +02:00
exit "$ret"