This makes git commit a builtin and moves git-commit.sh to
contrib/examples. This also removes the git-runstatus
helper, which was mostly just a git-status.sh implementation detail.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, when committing, git-commit ignore the value of
GIT_INDEX_FILE, and always use $GIT_DIR/index. This patch
fix it.
Signed-off-by: Rémi Vanicat <vanicat@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--text follows this line--
These commands currently lack OPTIONS_SPEC; allow people to
easily list with "git grep 'OPTIONS_SPEC=$'" what they can help
improving.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The checks that looked for paths given to git-commit in addition to
--all or --interactive expected only 3 values, while the case statement
actually provides 4, so the check was never triggered.
The bug was introduced in 6cbf07efc5 when
the case statement was extended to handle --interactive.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We rely on TMP_INDEX variable to decide if we are doing a partial commit,
as it is only set in the partial commit codepath. But the variable is
never initialized. A stray environment variable from outside could
ruin the day.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A lot of shell scripts contained stuff starting with
while case "$#" in 0) break ;; esac
and similar. I consider breaking out of the condition instead of the
body od the loop ugly, and the implied "true" value of the
non-matching case is not really obvious to humans at first glance. It
happens not to be obvious to some BSD shells, either, but that's
because they are not POSIX-compliant. In most cases, this has been
replaced by a straight condition using "test". "case" has the
advantage of being faster than "test" on vintage shells where "test"
is not a builtin. Since none of them is likely to run the git
scripts, anyway, the added readability should be worth the change.
A few loops have had their termination condition expressed
differently.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This moves "shift" out of the argument processing "case". It also
replaces quite a bit of expr calls with ${parameter#word} constructs,
and uses ${parameter:+word} for avoiding conditionals where possible.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because a partial commit is meant to be a way to ignore what are
staged in the index, "git rm --cached A && git commit A" should
just record what is in A on the filesystem. The previous patch
made the command sequence to barf, saying that A has not been
added yet. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When making a partial commit, git-commit uses git-ls-files with
the --error-unmatch option to expand and sanity check the user
supplied path patterns. When any path pattern does not match
with the paths known to the index, it errors out, in order to
catch a common mistake to say "git commit Makefiel cache.h"
and end up with a commit that touches only cache.h (notice the
misspelled "Makefile"). This detection however does not work
well when the path has already been removed from the index.
If you drop a path from the index and try to commit that
partially, i.e.
$ git rm COPYING
$ git commit -m 'Remove COPYING' COPYING
the command complains because git does not know anything about
COPYING anymore.
This introduces a new option --with-tree to git-ls-files and
uses it in git-commit when we build a temporary index to
write a tree object for the partial commit.
When --with-tree=<tree-ish> option is specified, names from the
given tree are added to the set of names the index knows about,
so we can treat COPYING file in the example as known.
Of course, there is no reason to use "git rm" and git-aware
people have long time done:
$ rm COPYING
$ git commit -m 'Remove COPYING' COPYING
which works just fine. But this caused a constant confusion.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because a partial commit is meant to be a way to ignore what are
staged in the index, "git rm --cached A && git commit A" should
just record what is in A on the filesystem. The previous patch
made the command sequence to barf, saying that A has not been
added yet. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When making a partial commit, git-commit uses git-ls-files with
the --error-unmatch option to expand and sanity check the user
supplied path patterns. When any path pattern does not match
with the paths known to the index, it errors out, in order to
catch a common mistake to say "git commit Makefiel cache.h"
and end up with a commit that touches only cache.h (notice the
misspelled "Makefile"). This detection however does not work
well when the path has already been removed from the index.
If you drop a path from the index and try to commit that
partially, i.e.
$ git rm COPYING
$ git commit -m 'Remove COPYING' COPYING
the command complains because git does not know anything about
COPYING anymore.
This introduces a new option --with-tree to git-ls-files and
uses it in git-commit when we build a temporary index to
write a tree object for the partial commit.
When --with-tree=<tree-ish> option is specified, names from the
given tree are added to the set of names the index knows about,
so we can treat COPYING file in the example as known.
Of course, there is no reason to use "git rm" and git-aware
people have long time done:
$ rm COPYING
$ git commit -m 'Remove COPYING' COPYING
which works just fine. But this caused a constant confusion.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Right now one can amend the last non-merge commit using a dirty index
and in the process maybe cause the last commit to have the same tree
as its parent. In such a case one would want to discard the last commit
instead of amending it.
This reverts commit 8588452ceb.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The point of auto gc is to pack new objects created in loose
format, so a good rule of thumb is where we do update-ref after
creating a new commit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of disabling color all of the time during a git-commit, allow
the user's config preference in the situation where there is nothing
to commit. In this situation, the status is printed to the terminal
and not sent to COMMIT_EDITMSG, so honoring the status color setting
is expected.
Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
[jc: adjusted t/t7501 as this makes -F and --amend compatible]
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are useful in organizations that enforce particular formats
for commit messages, e.g., to specify bug IDs or test plans.
Use of the template is not enforced; it is simply used as the
initial content when the editor is invoked.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These variables let you specify an editor that will be launched in
preference to the EDITOR and VISUAL environment variables. The order
of preference is GIT_EDITOR, core.editor, EDITOR, VISUAL.
[jc: added a test and config variable documentation]
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace uses of cat that do nothing but writing the contents of
a single file to another command via pipe.
[jc: Original patch from Josh was somewhat buggy and rewrote
"cat $file | wc -l" to "wc -l $file", but this one should be Ok.]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If requested to signoff a commit, don't add another Signed-off-by: line
to the commit message if the exact same line is already there.
This was noticed and requested by Josh Triplett through
http://bugs.debian.org/430851
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, "git rerere" was enabled by creating the directory
.git/rr-cache. That is definitely not in line with most other
features, which are enabled by a config variable.
So, check the config variable "rerere.enabled". If it is set
to "false" explicitely, do not activate rerere, even if
.git/rr-cache exists. This should help when you want to disable
rerere temporarily.
If "rerere.enabled" is not set at all, fall back to detection
of the directory .git/rr-cache.
[jc: with minimum tweaks]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At the moment, only git-commit uses that code, to pick the author name,
email and date from a given commit.
This code will be reused in git rebase --interactive.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes the same issue git-am had, which was fixed by Jeff
King in the previous commit. Cleverly enough, this commit's log
message is a good test case at the same time.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Useful e.g. to figure out what I did from screen history,
or to make sure subject line is short enough and makes sense
on its own.
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This corrects the interface mistake of the previous one, and
gives a command line parameter to the only plumbing command that
currently needs it: "git-read-tree".
We can add the calls to set_alternate_index_output() to other
plumbing commands that update the index if/when needed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When defined, this allows plumbing commands that update the
index (add, apply, checkout-index, merge-recursive, mv,
read-tree, rm, update-index, and write-tree) to write their
resulting index to an alternative index file while holding a
lock to the original index file. With this, git-commit that
jumps the index does not have to make an extra copy of the index
file, and more importantly, it can do the update while holding
the lock on the index.
However, I think the interface to let an environment variable
specify the output is a mistake, as shown in the documentation.
If a curious user has the environment variable set to something
other than the file GIT_INDEX_FILE points at, almost everything
will break. This should instead be a command line parameter to
tell these plumbing commands to write the result in the named
file, to prevent stupid mistakes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It still looks at the working tree and checks for locally
modified paths. When are preparing a temporary index from HEAD,
we do not want any of that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The --interactive option behaves like "git commit", except that
"git add --interactive" is executed before committing. It is
incompatible with -a and -i.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With current git:
$ git init
$ git commit -a
cp: cannot stat `.git/index': No such file or directory
Output a nice error message instead.
Signed-off-by: Fredrik Kuivinen <frekui@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes git-status work semi-decently in a read-only
repository. Earlier, the command simply died with "cannot lock
the index file" before giving any useful information to the
user.
Because index won't be updated in a read-only repository,
stat-dirty paths appear in the "Changed but not updated" list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows git-cherry-pick and git-revert to properly identify
themselves in the resulting reflog entries. Earlier they were
recorded as what git-commit has done.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to get the following confusing error message:
$ git commit --amend -a -m foo
Option -m cannot be combined with -c/-C/-F
This is because --amend cannot be combined with -c/-C/-F, which makes
sense, because they try to handle the same log message in different ways.
So update the documentation to reflect this.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier code discarded GIT_AUTHOR_DATE taken from the base
commit when --author was specified. This was often wrong as
that use is likely to fix the spelling of author's name.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The following commands can reuse log message from an existing
commit while creating a new commit:
git-cherry-pick
git-rebase (both with and without --merge)
git-commit (-c and -C)
When the original commit was made in a different encoding from
the current i18n.commitencoding, "cat-file commit" would give a
string that is inconsistent with what the resulting commit will
claim to be in. Replace them with "git show -s --encoding".
"git-rebase" without --merge is "git format-patch" piped to "git
am" in essence, and has been taken care of before this commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This converts scripts that do "cd $(rev-parse --show-cdup)" by
hand to use cd_to_toplevel.
I think git-fetch does not have to go to the toplevel, but that
should be dealt with in a separate patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user tries to run a porcelainish command which requires
a working directory in a bare repository they may get unexpected
results which are difficult to predict and may differ from command
to command.
Instead we should detect that the current repository is a bare
repository and refuse to run the command there, as there is no
working directory associated with it.
[jc: updated Shawn's original somewhat -- bugs are mine.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a user modifies files and runs 'git commit' (without the very
useful -a option) and they have not yet updated the index they
are probably coming from another SCM-like tool which would perform
the same as 'git commit -a' in this case. Showing the user their
current status and a final line of "nothing to commit" is not very
reassuring, as the user might believe that Git did not recognize
their files were modified.
Instead we can suggest as part of the 'nothing to commit' message
that the user invoke 'git add' to add files to their next commit.
Suggested by Andy Parkins' Git 'niggles' list
(<200612132237.10051.andyparkins@gmail.com>).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is nicer to let the user know when a commit succeeded all the time,
not only the first time. Also the commit sha1 is much more useful than
the tree sha1 in this case.
This patch also introduces a -q switch to supress this message as well
as the summary of created/deleted files.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The command used to have a safety valve to prevent this sequence:
edit foo
git update-index foo
edit foo
git diff foo
git commit --only foo
The reason for this was because an inexperienced user might
mistakenly think what is shown with the last-minute diff
contains all the change that is being committed (instead, what
the user asked to check was an incremental diff since what has
been staged so far). However, this turns out to only annoy
people who know what they are doing. Inexperienced people
would not be using the first "update-index" anyway, in which
case they would see the full changes in the "git diff".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes people accidentally commit files in wrong mode bits.
Show --summary output for the HEAD commit after successful commit
as a final sanity check.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a busy project, reverting a commit almost always results
in a conflict between one or more files (depending on the
commit being reverted). It is useful to record this
conflict in the commit-to-be message of the resulting commit
(after the resolve). The process now becomes:
git-revert <SHA-1>
<git complains and prints failed automatic>
<user manually resolves>
git-update-index <resolved files>
git-commit -s
And the commit message is now a merge of the revert commit
message and the conflict commit message, giving the user a
chance to edit it or add more information:
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-commit.sh was using a mixture of spaces and tabs for indentation.
This is changed to one tab per indentation level.
No code changes.
Signed-off-by: Martin Waitz <tali@admingilde.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Todd Zullinger