With "status.short" set, it is now impossible to commit with
status.short set, because it acts like "git commit --short", and it
is impossible to differentiate between a status_format set by the
command-line option parser versus that set by the config parser.

To alleviate this problem, clear status_format as soon as the config
parser has finished its work.
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some people often run 'git status -b'.
The config variable status.branch allows to set it by default.
Signed-off-by: NJorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
Signed-off-by: NMathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Reviewed-by: NMatthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: NMatthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some people always run 'git status -s'.
The configuration variable status.short allows to set it by default.
Signed-off-by: NJorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
Signed-off-by: NMathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Reviewed-by: NMatthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: NMatthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The commit encoding is parsed by logmsg_reencode, there's no need for
the caller to re-parse it again. The reencoded message now has the new
encoding, not the original one. The caller would need to read commit
object again before parsing.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently, git will append two newlines to every message supplied via
the -m switch.  The purpose of this is to allow -m to be supplied
multiple times and have each supplied string become a paragraph in the
resulting commit message.

Normally, this does not cause a problem since any trailing newlines will
be removed by the cleanup operation.  If cleanup=verbatim for example,
then the trailing newlines will not be removed and will survive into the
resulting commit message.

Instead, let's ensure that the string supplied to -m is newline terminated,
but only append a second newline when appending additional messages.

Fixes the test in t7502.
Signed-off-by: NBrandon Casey <drafnel@gmail.com>
Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
This is in preparation to unify the append_signoff implementations in
log-tree.c and sequencer.c.

Fixes test in t3511.
Signed-off-by: NBrandon Casey <bcasey@nvidia.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

pathspec is the most widely used term, and is the one defined in
gitglossary.txt. <filepattern> was used only in the synopsys for git-add
and git-commit, and in git-add.txt. Get rid of it.

This patch is obtained with by running:

  perl -pi -e 's/filepattern/pathspec/' `git grep -l filepattern`
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The logmsg_reencode function will return the reencoded
commit buffer, or NULL if reencoding failed or no reencoding
was necessary. Since every caller then ends up checking for NULL
and just using the commit's original buffer, anyway, we can
be a bit more helpful and just return that buffer when we
would have returned NULL.

Since the resulting string may or may not need to be freed,
we introduce a logmsg_free, which checks whether the buffer
came from the commit object or not (callers either
implemented the same check already, or kept two separate
pointers, one to mark the buffer to be used, and one for the
to-be-freed string).

Pushing this logic into logmsg_* simplifies the callers, and
will let future patches lazily load the commit buffer in a
single place.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When git-commit is asked to reuse a commit message via "-c",
we call read_commit_message, which looks up the commit and
hands back either the re-encoded result, or a copy of the
original. We make a copy in the latter case so that the
ownership semantics of the return value are clear (in either
case, it can be freed).

However, since we return a "const char *", and since the
resulting buffer's lifetime is the same as that of the whole
program, we never bother to free it at all.

Let's just drop the copy. That saves us a copy in the common
case. While it does mean we leak in the re-encode case, it
doesn't matter, since we are relying on program exit to free
the memory anyway.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some users do want to write a line that begin with a pound sign, #,
in their commit log message.  Many tracking system recognise
a token of #<bugid> form, for example.

The support we offer these use cases is not very friendly to the end
users.  They have a choice between

 - Don't do it.  Avoid such a line by rewrapping or indenting; and

 - Use --cleanup=whitespace but remove all the hint lines we add.

Give them a way to set a custom comment char, e.g.

    $ git -c core.commentchar="%" commit

so that they do not have to do either of the two workarounds.

[jc: although I started the topic, all the tests and documentation
updates, many of the call sites of the new strbuf_add_commented_*()
functions, and the change to git-submodule.sh scripted Porcelain are
from Ralf.]
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Create find_hook() function to determine if a given hook exists and is
executable.  If it is, the path to the script will be returned,
otherwise NULL is returned.

This encapsulates the tests that are used to check for the existence of
a hook in one place, making it easier to modify those checks if that is
found to be necessary.  This also makes it simple for places that can
use a hook to check if a hook exists before doing, possibly lengthy,
setup work which would be pointless if no such hook is present.

The returned value is left as a static value from get_pathname() rather
than a duplicate because it is anticipated that the return value will
either be used as a boolean, immediately added to an argv_array list
which would result in it being duplicated at that point, or used to
actually run the command without much intervening work.  Callers which
need to hold onto the returned value for a longer time are expected to
duplicate the return value themselves.
Signed-off-by: NAaron Schrab <aaron@schrab.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The default of the "cleanup" option in "git commit"
is not configurable. Users who don't want to use the
default have to pass this option on every commit since
there's no way to configure it. This commit introduces
a new config option "commit.cleanup" which can be used
to change the default of the "cleanup" option in
"git commit".
Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We keep track of whether the user ident was given to us
explicitly, or if we guessed at it from system parameters
like username and hostname. However, we kept only a single
variable. This covers the common cases (because the author
and committer will usually come from the same explicit
source), but can miss two cases:

  1. GIT_COMMITTER_* is set explicitly, but we fallback for
     GIT_AUTHOR. We claim the ident is explicit, even though
     the author is not.

  2. GIT_AUTHOR_* is set and we ask for author ident, but
     not committer ident. We will claim the ident is
     implicit, even though it is explicit.

This patch uses two variables instead of one, updates both
when we set the "fallback" values, and updates them
individually when we read from the environment.

Rather than keep user_ident_sufficiently_given as a
compatibility wrapper, we update the only two callers to
check the committer_ident, which matches their intent and
what was happening already.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

You can currently set the output format to --short or
--porcelain. There is no --long, because we default to it
already. However, you may want to override an alias that
uses "--short" to get back to the default.

This requires a little bit of refactoring, because currently
we use STATUS_FORMAT_LONG internally to mean the same as
"the user did not specify anything". By expanding the enum
to include STATUS_FORMAT_NONE, we can distinguish between
the implicit and explicit cases. This effects these
conditions:

  1. The user has asked for NUL termination. With NONE, we
     currently default to turning on the porcelain mode.
     With an explicit --long, we would in theory use NUL
     termination with the long mode, but it does not support
     it. So we can just complain and die.

  2. When an output format is given to "git commit", we
     default to "--dry-run". This behavior would now kick in
     when "--long" is given, too.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

"git status" does not list a submodule with uncommitted working tree
files as modified when "submodule.$name.ignore" is set to "dirty" in
in-tree ".gitmodules" file.  Both status and commit honor the setting
in $GIT_DIR/config, but "commit" does not pick it up from .gitmodules,
which is inconsistent.

Teach "git commit" to pay attention to the setting in .gitmodules as
well.
Signed-off-by: NOrgad Shaneh <orgads@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In case 'git cherry-pick -s <commit>' failed, the user had to use 'git
commit -s' (i.e. state the -s option again), which is easy to forget
about.  Instead, write the signed-off-by line early, so plain 'git
commit' will have the same result.

Also update 'git commit -s', so that in case there is already a relevant
Signed-off-by line before the Conflicts: line, it won't add one more at
the end of the message. If there is no such line, then add it before the
the Conflicts: line.
Signed-off-by: NMiklos Vajna <vmiklos@suse.cz>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Commits made by ancient version of Git allowed committer without
human readable name, like this (00213b17c in the kernel history):

    tree 6947dba41f8b0e7fe7bccd41a4840d6de6a27079
    parent 352dd1df32e672be4cff71132eb9c06a257872fe
    author Petr Baudis <pasky@ucw.cz> 1135223044 +0100
    committer  <sam@mars.ravnborg.org> 1136151043 +0100

    kconfig: Remove support for lxdialog --checklist

    ...
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

When fed such a commit, --format='%ci' fails to parse it, and gives
back an empty string.  Update the split_ident_line() to be a bit
more lenient when parsing, but make sure the caller that wants to
pick up sane value from its return value does its own validation.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The identity of the committer will ultimately be pulled from
the ident code by commit_tree(). However, we make an attempt
to check the author and committer identity early, before the
user has done any manual work like inputting a commit
message. That lets us abort without them having to worry
about salvaging the work from .git/COMMIT_EDITMSG.

The early check for committer ident does not use the
IDENT_STRICT flag, meaning that it would not find an empty
name field. The motivation was presumably because we did not
want to be too restrictive, as later calls might be more lax
(for example, when we create the reflog entry, we do not
care too much about a real name). However, because
commit_tree will always get a strict identity to put in the
commit object itself, there is no point in being lax only to
die later (and in fact it is harmful, because the user will
have wasted time typing their commit message).

Incidentally, this bug was masked prior to 060d4bb3, as the
initial loose call would taint the later strict call. So the
commit would succeed (albeit with a bogus committer line in
the commit object), and nobody noticed that our early check
did not match the later one.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

"git commit --amend" used on a commit with an empty message fails
unless -m is given, whether or not --allow-empty-message is
specified.

Allow it to proceed to the editor with an empty commit message.
Unless --allow-empty-message is in force, it will still abort later
if an empty message is saved from the editor (this check was
already necessary to prevent a non-empty commit message being edited
to an empty one).

Add a test for --amend --edit of an empty commit message which fails
without this fix, as it's a rare case that won't get frequently
tested otherwise.
Signed-off-by: NChris Webb <chris@arachsys.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Callers who ask for ERROR_ON_NO_NAME are not so much
concerned that the name will be blank (because, after all,
we will fall back to using the username), but rather it is a
check to make sure that low-quality identities do not end up
in things like commit messages or emails (whereas it is OK
for them to end up in things like reflogs).

When future commits add more quality checks on the identity,
each of these callers would want to use those checks, too.
Rather than modify each of them later to add a new flag,
let's refactor the flag.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The current code reads the config and command-line options
into a separate "colopts" variable, and then copies the
contents of that variable into the "struct wt_status". We
can eliminate the extra variable and copy just write
straight into the wt_status struct.

This simplifies the "status" code a little bit.
Unfortunately, it makes the "commit" code one line more
complex; a side effect of the separate variable was that
"commit" did not copy the colopts variable, so any
column.status configuration had no effect.

The result still ends up cleaner, though. In the previous
version, it was unclear whether commit simply forgot to copy
the colopt variable, or whether it was intentional. Now it
explicitly turns off column options. Furthermore, if commit
later learns to respect column.status, this will make the
end result simpler. I punted on just adding that feature
now, because it was sufficiently non-obvious that it should
not go into a refactoring patch.
Signed-off-by: NJeff King <peff@peff.net>

There is no reason not to, as the user has to explicitly ask
for it, so we are not breaking compatibility by doing so. We
can do this simply by moving the "show_branch" flag into
the wt_status struct. As a bonus, this saves us from passing
it explicitly, simplifying the code.
Signed-off-by: NJeff King <peff@peff.net>

This option is passed separately to the wt_status printing
functions, whereas every other formatting option is
contained in the wt_status struct itself. Let's do the same
here, so we can avoid passing it around through the call
stack.
Signed-off-by: NJeff King <peff@peff.net>

The options are declared as a static global, but really they
need only be accessible from cmd_commit.  Additionally,
declare the "struct wt_status" in cmd_commit and cmd_status
as static at the top of each function; this will let the
options lists reference them directly, which will facilitate
further cleanups.
Signed-off-by: NJeff King <peff@peff.net>

Change the "Please enter the commit message for your changes." and the
subsequent blurb of text not to be split up. This makes translating it
much easier.
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Remove the whence_s() function and messages that depend on it, in favor of
messages that use either "merge" or "cherry-pick" directly.
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When the user exited editor without editing the commit log template given
by "git commit -t <template>", the commit was aborted (correct) with an
error message that said "due to empty commit message" (incorrect).

This was because the original template support was done by piggybacking on
the check to detect an empty log message.  Split the codepaths into two
independent checks to clarify the error.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When "-t template" and "-F msg" options are both given (or worse yet,
there is "commit.template" configuration but a message is given in some
other way), the documentation says that template is ignored.  However,
the "has the user edited the message?" check still used the contents of
the template file as the basis of the emptyness check.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When lying the author name via GIT_AUTHOR_NAME environment variable
to "git commit", the hooks run by the command saw it and could act
on the name that will be recorded in the final commit. When the user
uses the "--author" option from the command line, the command should
give the same information to the hook, and back when "git command"
was a scripted Porcelain, it did set the environment variable and
hooks can learn the author name from it.

However, when the command was reimplemented in C, the rewritten code
was not very faithful to the original, and hooks stopped getting the
authorship information given with "--author".  Fix this by exporting
the necessary environment variables.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The only place that the issue this series addresses was observed
where we read "cat-file commit" output and put it in GIT_AUTHOR_DATE
in order to replay a commit with an ancient timestamp.

With the previous patch alone, "git commit --date='20100917 +0900'"
can be misinterpreted to mean an ancient timestamp, not September in
year 2010.  Guard this codepath by requring an extra '@' in front of
the raw git timestamp on the parsing side. This of course needs to
be compensated by updating get_author_ident_from_commit and the code
for "git commit --amend" to prepend '@' to the string read from the
existing commit in the GIT_AUTHOR_DATE environment variable.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Mark the "merge/cherry-pick" messages in whence_s for translation.
These messages returned from whence_s function are used as argument
to build other messages.
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Any existing commit signature was made against the contents of the old
commit, including its committer date that is about to change, and will
become invalid by amending it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The earlier ed7a42a0 (commit: teach --amend to carry forward extra headers,
2011-11-08) broke "git merge/pull; edit to fix conflict; git commit"
workflow by forgetting that commit_tree_extended() takes the whole extra
header list.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There wan't a way for commit_tree() to notice if the message the caller
prepared contained a NUL byte, as it did not take the length of the
message as a parameter. Use a pointer to a strbuf instead, so that we can
either choose to allow low-level plumbing commands to make commits that
contain NUL byte in its message, or forbid NUL everywhere by adding the
check in commit_tree(), in later patches.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

resolve_ref() may return a pointer to a shared buffer and can be
overwritten by the next resolve_ref() calls. Callers need to
pay attention, not to keep the pointer when the next call happens.

Rename with "_unsafe" suffix to warn developers (or reviewers) before
introducing new call sites.

This patch is generated using the following command

git grep -l 'resolve_ref(' -- '*.[ch]'|xargs sed -i 's/resolve_ref(/resolve_ref_unsafe(/g'
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

After making fixes to the contents to be committed, it is not unusual to
update the current commit without rewording the message. Idioms to tell
"commit --amend" that we do not need an editor have been:

    $ EDITOR=: git commit --amend
    $ git commit --amend -C HEAD

but that was only because a more natural "--no-edit" option in

    $ git commit --amend --no-edit

was not honoured.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>