2007-11-08 16:59:00 +00:00
|
|
|
/*
|
|
|
|
* Builtin "git commit"
|
|
|
|
*
|
|
|
|
* Copyright (c) 2007 Kristian Høgsberg <krh@redhat.com>
|
|
|
|
* Based on git-commit.sh by Junio C Hamano and Linus Torvalds
|
|
|
|
*/
|
|
|
|
|
2023-02-10 10:28:39 +00:00
|
|
|
#define USE_THE_INDEX_VARIABLE
|
2023-05-16 06:33:57 +00:00
|
|
|
#include "builtin.h"
|
2023-04-11 03:00:39 +00:00
|
|
|
#include "advice.h"
|
2017-06-14 18:07:36 +00:00
|
|
|
#include "config.h"
|
2014-10-01 10:28:42 +00:00
|
|
|
#include "lockfile.h"
|
2007-11-08 16:59:00 +00:00
|
|
|
#include "cache-tree.h"
|
2008-02-18 07:26:03 +00:00
|
|
|
#include "color.h"
|
2007-11-18 09:52:55 +00:00
|
|
|
#include "dir.h"
|
2023-04-11 07:41:57 +00:00
|
|
|
#include "editor.h"
|
2023-03-21 06:25:57 +00:00
|
|
|
#include "environment.h"
|
2007-11-08 16:59:00 +00:00
|
|
|
#include "diff.h"
|
|
|
|
#include "diffcore.h"
|
|
|
|
#include "commit.h"
|
2023-03-21 06:25:54 +00:00
|
|
|
#include "gettext.h"
|
2007-11-08 16:59:00 +00:00
|
|
|
#include "revision.h"
|
|
|
|
#include "wt-status.h"
|
|
|
|
#include "run-command.h"
|
2021-09-26 19:03:26 +00:00
|
|
|
#include "hook.h"
|
2007-11-08 16:59:00 +00:00
|
|
|
#include "refs.h"
|
|
|
|
#include "log-tree.h"
|
|
|
|
#include "strbuf.h"
|
|
|
|
#include "utf8.h"
|
2023-04-11 07:41:49 +00:00
|
|
|
#include "object-name.h"
|
2007-11-08 16:59:00 +00:00
|
|
|
#include "parse-options.h"
|
2023-05-16 06:33:59 +00:00
|
|
|
#include "path.h"
|
2023-05-16 06:33:52 +00:00
|
|
|
#include "preload-index.h"
|
2023-05-16 06:33:56 +00:00
|
|
|
#include "read-cache.h"
|
2008-07-21 18:03:49 +00:00
|
|
|
#include "string-list.h"
|
2008-07-09 12:58:57 +00:00
|
|
|
#include "rerere.h"
|
2008-01-13 08:30:56 +00:00
|
|
|
#include "unpack-trees.h"
|
2009-08-08 06:31:57 +00:00
|
|
|
#include "quote.h"
|
2010-08-05 22:40:48 +00:00
|
|
|
#include "submodule.h"
|
commit: teach --gpg-sign option
This uses the gpg-interface.[ch] to allow signing the commit, i.e.
$ git commit --gpg-sign -m foo
You need a passphrase to unlock the secret key for
user: "Junio C Hamano <gitster@pobox.com>"
4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
[master 8457d13] foo
1 files changed, 1 insertions(+), 0 deletions(-)
The lines of GPG detached signature are placed in a new multi-line header
field, instead of tucking the signature block at the end of the commit log
message text (similar to how signed tag is done), for multiple reasons:
- The signature won't clutter output from "git log" and friends if it is
in the extra header. If we place it at the end of the log message, we
would need to teach "git log" and friends to strip the signature block
with an option.
- Teaching new versions of "git log" and "gitk" to optionally verify and
show signatures is cleaner if we structurally know where the signature
block is (instead of scanning in the commit log message).
- The signature needs to be stripped upon various commit rewriting
operations, e.g. rebase, filter-branch, etc. They all already ignore
unknown headers, but if we place signature in the log message, all of
these tools (and third-party tools) also need to learn how a signature
block would look like.
- When we added the optional encoding header, all the tools (both in tree
and third-party) that acts on the raw commit object should have been
fixed to ignore headers they do not understand, so it is not like that
new header would be more likely to break than extra text in the commit.
A commit made with the above sample sequence would look like this:
$ git cat-file commit HEAD
tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
parent b87755351a47b09cb27d6913e6e0e17e6254a4d4
author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG
...
=dt98
-----END PGP SIGNATURE-----
foo
but "git log" (unless you ask for it with --pretty=raw) output is not
cluttered with the signature information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 00:23:20 +00:00
|
|
|
#include "gpg-interface.h"
|
2012-04-13 10:54:39 +00:00
|
|
|
#include "column.h"
|
2012-09-14 06:52:03 +00:00
|
|
|
#include "sequencer.h"
|
2023-05-16 06:33:51 +00:00
|
|
|
#include "sparse-index.h"
|
2013-08-23 13:48:31 +00:00
|
|
|
#include "mailmap.h"
|
2018-05-26 13:55:24 +00:00
|
|
|
#include "help.h"
|
2018-07-20 16:33:04 +00:00
|
|
|
#include "commit-reach.h"
|
2018-08-29 12:49:04 +00:00
|
|
|
#include "commit-graph.h"
|
date API: create a date.h, split from cache.h
Move the declaration of the date.c functions from cache.h, and adjust
the relevant users to include the new date.h header.
The show_ident_date() function belonged in pretty.h (it's defined in
pretty.c), its two users outside of pretty.c didn't strictly need to
include pretty.h, as they get it indirectly, but let's add it to them
anyway.
Similarly, the change to "builtin/{fast-import,show-branch,tag}.c"
isn't needed as far as the compiler is concerned, but since they all
use the "DATE_MODE()" macro we now define in date.h, let's have them
include it.
We could simply include this new header in "cache.h", but as this
change shows these functions weren't common enough to warrant
including in it in the first place. By moving them out of cache.h
changes to this API will no longer cause a (mostly) full re-build of
the project when "make" is run.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-16 08:14:02 +00:00
|
|
|
#include "pretty.h"
|
2007-11-08 16:59:00 +00:00
|
|
|
|
|
|
|
static const char * const builtin_commit_usage[] = {
|
2022-10-13 15:39:23 +00:00
|
|
|
N_("git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]\n"
|
|
|
|
" [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>)]\n"
|
|
|
|
" [-F <file> | -m <msg>] [--reset-author] [--allow-empty]\n"
|
|
|
|
" [--allow-empty-message] [--no-verify] [-e] [--author=<author>]\n"
|
|
|
|
" [--date=<date>] [--cleanup=<mode>] [--[no-]status]\n"
|
|
|
|
" [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]\n"
|
|
|
|
" [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]\n"
|
|
|
|
" [--] [<pathspec>...]"),
|
2007-11-08 16:59:00 +00:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2007-12-03 05:02:09 +00:00
|
|
|
static const char * const builtin_status_usage[] = {
|
2022-10-13 15:39:21 +00:00
|
|
|
N_("git status [<options>] [--] [<pathspec>...]"),
|
2007-12-03 05:02:09 +00:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2010-06-07 00:41:46 +00:00
|
|
|
static const char empty_amend_advice[] =
|
2011-02-22 23:41:49 +00:00
|
|
|
N_("You asked to amend the most recent commit, but doing so would make\n"
|
2010-06-07 00:41:46 +00:00
|
|
|
"it empty. You can repeat your command with --allow-empty, or you can\n"
|
2011-02-22 23:41:49 +00:00
|
|
|
"remove the commit entirely with \"git reset HEAD^\".\n");
|
2010-06-07 00:41:46 +00:00
|
|
|
|
2011-02-20 04:12:29 +00:00
|
|
|
static const char empty_cherry_pick_advice[] =
|
2011-04-02 00:55:55 +00:00
|
|
|
N_("The previous cherry-pick is now empty, possibly due to conflict resolution.\n"
|
2011-02-20 04:12:29 +00:00
|
|
|
"If you wish to commit it anyway, use:\n"
|
|
|
|
"\n"
|
|
|
|
" git commit --allow-empty\n"
|
commit: tweak empty cherry pick advice for sequencer
When we refuse to make an empty commit, we check whether we
are in a cherry-pick in order to give better advice on how
to proceed. We instruct the user to repeat the commit with
"--allow-empty" to force the commit, or to use "git reset"
to skip it and abort the cherry-pick.
In the case of a single cherry-pick, the distinction between
skipping and aborting is not important, as there is no more
work to be done afterwards. When we are using the sequencer
to cherry pick a series of commits, though, the instruction
is confusing: does it skip this commit, or does it abort the
rest of the cherry-pick?
It does skip, after which the user can continue the
cherry-pick. This is the right thing to be advising the user
to do, but let's make it more clear what will happen, both
by using the word "skip", and by mentioning that the rest of
the sequence can be continued via "cherry-pick --continue"
(whether we skip or take the commit).
Noticed-by: Ramkumar Ramachandra <artagnon@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-26 23:39:28 +00:00
|
|
|
"\n");
|
|
|
|
|
2019-12-06 16:06:12 +00:00
|
|
|
static const char empty_rebase_pick_advice[] =
|
|
|
|
N_("Otherwise, please use 'git rebase --skip'\n");
|
|
|
|
|
commit: tweak empty cherry pick advice for sequencer
When we refuse to make an empty commit, we check whether we
are in a cherry-pick in order to give better advice on how
to proceed. We instruct the user to repeat the commit with
"--allow-empty" to force the commit, or to use "git reset"
to skip it and abort the cherry-pick.
In the case of a single cherry-pick, the distinction between
skipping and aborting is not important, as there is no more
work to be done afterwards. When we are using the sequencer
to cherry pick a series of commits, though, the instruction
is confusing: does it skip this commit, or does it abort the
rest of the cherry-pick?
It does skip, after which the user can continue the
cherry-pick. This is the right thing to be advising the user
to do, but let's make it more clear what will happen, both
by using the word "skip", and by mentioning that the rest of
the sequence can be continued via "cherry-pick --continue"
(whether we skip or take the commit).
Noticed-by: Ramkumar Ramachandra <artagnon@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-26 23:39:28 +00:00
|
|
|
static const char empty_cherry_pick_advice_single[] =
|
2019-07-02 09:11:29 +00:00
|
|
|
N_("Otherwise, please use 'git cherry-pick --skip'\n");
|
commit: tweak empty cherry pick advice for sequencer
When we refuse to make an empty commit, we check whether we
are in a cherry-pick in order to give better advice on how
to proceed. We instruct the user to repeat the commit with
"--allow-empty" to force the commit, or to use "git reset"
to skip it and abort the cherry-pick.
In the case of a single cherry-pick, the distinction between
skipping and aborting is not important, as there is no more
work to be done afterwards. When we are using the sequencer
to cherry pick a series of commits, though, the instruction
is confusing: does it skip this commit, or does it abort the
rest of the cherry-pick?
It does skip, after which the user can continue the
cherry-pick. This is the right thing to be advising the user
to do, but let's make it more clear what will happen, both
by using the word "skip", and by mentioning that the rest of
the sequence can be continued via "cherry-pick --continue"
(whether we skip or take the commit).
Noticed-by: Ramkumar Ramachandra <artagnon@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-26 23:39:28 +00:00
|
|
|
|
|
|
|
static const char empty_cherry_pick_advice_multi[] =
|
2019-07-02 09:11:29 +00:00
|
|
|
N_("and then use:\n"
|
2011-02-20 04:12:29 +00:00
|
|
|
"\n"
|
2019-07-02 09:11:29 +00:00
|
|
|
" git cherry-pick --continue\n"
|
commit: tweak empty cherry pick advice for sequencer
When we refuse to make an empty commit, we check whether we
are in a cherry-pick in order to give better advice on how
to proceed. We instruct the user to repeat the commit with
"--allow-empty" to force the commit, or to use "git reset"
to skip it and abort the cherry-pick.
In the case of a single cherry-pick, the distinction between
skipping and aborting is not important, as there is no more
work to be done afterwards. When we are using the sequencer
to cherry pick a series of commits, though, the instruction
is confusing: does it skip this commit, or does it abort the
rest of the cherry-pick?
It does skip, after which the user can continue the
cherry-pick. This is the right thing to be advising the user
to do, but let's make it more clear what will happen, both
by using the word "skip", and by mentioning that the rest of
the sequence can be continued via "cherry-pick --continue"
(whether we skip or take the commit).
Noticed-by: Ramkumar Ramachandra <artagnon@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-26 23:39:28 +00:00
|
|
|
"\n"
|
2019-07-02 09:11:29 +00:00
|
|
|
"to resume cherry-picking the remaining commits.\n"
|
|
|
|
"If you wish to skip this commit, use:\n"
|
|
|
|
"\n"
|
|
|
|
" git cherry-pick --skip\n"
|
|
|
|
"\n");
|
2011-02-20 04:12:29 +00:00
|
|
|
|
2018-05-26 13:55:21 +00:00
|
|
|
static const char *color_status_slots[] = {
|
|
|
|
[WT_STATUS_HEADER] = "header",
|
|
|
|
[WT_STATUS_UPDATED] = "updated",
|
|
|
|
[WT_STATUS_CHANGED] = "changed",
|
|
|
|
[WT_STATUS_UNTRACKED] = "untracked",
|
|
|
|
[WT_STATUS_NOBRANCH] = "noBranch",
|
|
|
|
[WT_STATUS_UNMERGED] = "unmerged",
|
|
|
|
[WT_STATUS_LOCAL_BRANCH] = "localBranch",
|
|
|
|
[WT_STATUS_REMOTE_BRANCH] = "remoteBranch",
|
|
|
|
[WT_STATUS_ONBRANCH] = "branch",
|
|
|
|
};
|
|
|
|
|
2011-02-20 04:12:29 +00:00
|
|
|
static const char *use_message_buffer;
|
2007-11-18 09:52:55 +00:00
|
|
|
static struct lock_file index_lock; /* real index */
|
|
|
|
static struct lock_file false_lock; /* used only for partial commits */
|
|
|
|
static enum {
|
|
|
|
COMMIT_AS_IS = 1,
|
|
|
|
COMMIT_NORMAL,
|
2010-05-14 09:31:35 +00:00
|
|
|
COMMIT_PARTIAL
|
2007-11-18 09:52:55 +00:00
|
|
|
} commit_style;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2008-08-06 18:43:47 +00:00
|
|
|
static const char *logfile, *force_author;
|
2008-07-05 05:24:40 +00:00
|
|
|
static const char *template_file;
|
2011-02-20 04:12:29 +00:00
|
|
|
/*
|
|
|
|
* The _message variables are commit names from which to take
|
|
|
|
* the commit message and/or authorship.
|
|
|
|
*/
|
|
|
|
static const char *author_message, *author_message_buffer;
|
2007-11-08 16:59:00 +00:00
|
|
|
static char *edit_message, *use_message;
|
2021-03-15 07:54:32 +00:00
|
|
|
static char *fixup_message, *fixup_commit, *squash_message;
|
|
|
|
static const char *fixup_prefix;
|
2011-12-06 21:09:55 +00:00
|
|
|
static int all, also, interactive, patch_interactive, only, amend, signoff;
|
|
|
|
static int edit_flag = -1; /* unspecified */
|
2009-11-04 03:20:11 +00:00
|
|
|
static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
|
2016-05-05 09:50:02 +00:00
|
|
|
static int config_commit_verbose = -1; /* unspecified */
|
2019-11-19 16:48:55 +00:00
|
|
|
static int no_post_rewrite, allow_empty_message, pathspec_file_nul;
|
status: add option to show ignored files differently
Teach the status command more flexibility in how ignored files are
reported. Currently, the reporting of ignored files and untracked
files are linked. You cannot control how ignored files are reported
independently of how untracked files are reported (i.e. `all` vs
`normal`). This makes it impossible to show untracked files with the
`all` option, but show ignored files with the `normal` option.
This work 1) adds the ability to control the reporting of ignored
files independently of untracked files and 2) introduces the concept
of status reporting ignored paths that explicitly match an ignored
pattern. There are 2 benefits to these changes: 1) if a consumer needs
all untracked files but not all ignored files, there is a performance
benefit to not scanning all contents of an ignored directory and 2)
returning ignored files that explicitly match a path allow a consumer
to make more informed decisions about when a status result might be
stale.
This commit implements --ignored=matching with --untracked-files=all.
The following commit will implement --ignored=matching with
--untracked=files=normal.
As an example of where this flexibility could be useful is that our
application (Visual Studio) runs the status command and presents the
output. It shows all untracked files individually (e.g. using the
'--untracked-files==all' option), and would like to know about which
paths are ignored. It uses information about ignored paths to make
decisions about when the status result might have changed.
Additionally, many projects place build output into directories inside
a repository's working directory (e.g. in "bin/" and "obj/"
directories). Normal usage is to explicitly ignore these 2 directory
names in the .gitignore file (rather than or in addition to the *.obj
pattern).If an application could know that these directories are
explicitly ignored, it could infer that all contents are ignored as
well and make better informed decisions about files in these
directories. It could infer that any changes under these paths would
not affect the output of status. Additionally, there can be a
significant performance benefit by avoiding scanning through ignored
directories.
When status is set to report matching ignored files, it has the
following behavior. Ignored files and directories that explicitly
match an exclude pattern are reported. If an ignored directory matches
an exclude pattern, then the path of the directory is returned. If a
directory does not match an exclude pattern, but all of its contents
are ignored, then the contained files are reported instead of the
directory.
Signed-off-by: Jameson Miller <jamill@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-30 17:21:37 +00:00
|
|
|
static char *untracked_files_arg, *force_date, *ignore_submodule_arg, *ignored_arg;
|
2019-11-19 16:48:55 +00:00
|
|
|
static char *sign_commit, *pathspec_from_file;
|
2021-03-23 13:55:57 +00:00
|
|
|
static struct strvec trailer_args = STRVEC_INIT;
|
commit: teach --gpg-sign option
This uses the gpg-interface.[ch] to allow signing the commit, i.e.
$ git commit --gpg-sign -m foo
You need a passphrase to unlock the secret key for
user: "Junio C Hamano <gitster@pobox.com>"
4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
[master 8457d13] foo
1 files changed, 1 insertions(+), 0 deletions(-)
The lines of GPG detached signature are placed in a new multi-line header
field, instead of tucking the signature block at the end of the commit log
message text (similar to how signed tag is done), for multiple reasons:
- The signature won't clutter output from "git log" and friends if it is
in the extra header. If we place it at the end of the log message, we
would need to teach "git log" and friends to strip the signature block
with an option.
- Teaching new versions of "git log" and "gitk" to optionally verify and
show signatures is cleaner if we structurally know where the signature
block is (instead of scanning in the commit log message).
- The signature needs to be stripped upon various commit rewriting
operations, e.g. rebase, filter-branch, etc. They all already ignore
unknown headers, but if we place signature in the log message, all of
these tools (and third-party tools) also need to learn how a signature
block would look like.
- When we added the optional encoding header, all the tools (both in tree
and third-party) that acts on the raw commit object should have been
fixed to ignore headers they do not understand, so it is not like that
new header would be more likely to break than extra text in the commit.
A commit made with the above sample sequence would look like this:
$ git cat-file commit HEAD
tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
parent b87755351a47b09cb27d6913e6e0e17e6254a4d4
author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG
...
=dt98
-----END PGP SIGNATURE-----
foo
but "git log" (unless you ask for it with --pretty=raw) output is not
cluttered with the signature information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 00:23:20 +00:00
|
|
|
|
2007-12-22 18:46:24 +00:00
|
|
|
/*
|
|
|
|
* The default commit message cleanup mode will remove the lines
|
|
|
|
* beginning with # (shell comments) and leading and trailing
|
|
|
|
* whitespaces (empty lines or containing only whitespaces)
|
|
|
|
* if editor is used, and only the whitespaces if the message
|
|
|
|
* is specified explicitly.
|
|
|
|
*/
|
2017-11-10 11:09:42 +00:00
|
|
|
static enum commit_msg_cleanup_mode cleanup_mode;
|
2013-01-10 17:45:59 +00:00
|
|
|
static const char *cleanup_arg;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2011-02-20 04:12:29 +00:00
|
|
|
static enum commit_whence whence;
|
2011-08-19 18:58:18 +00:00
|
|
|
static int use_editor = 1, include_status = 1;
|
status: add option to show ignored files differently
Teach the status command more flexibility in how ignored files are
reported. Currently, the reporting of ignored files and untracked
files are linked. You cannot control how ignored files are reported
independently of how untracked files are reported (i.e. `all` vs
`normal`). This makes it impossible to show untracked files with the
`all` option, but show ignored files with the `normal` option.
This work 1) adds the ability to control the reporting of ignored
files independently of untracked files and 2) introduces the concept
of status reporting ignored paths that explicitly match an ignored
pattern. There are 2 benefits to these changes: 1) if a consumer needs
all untracked files but not all ignored files, there is a performance
benefit to not scanning all contents of an ignored directory and 2)
returning ignored files that explicitly match a path allow a consumer
to make more informed decisions about when a status result might be
stale.
This commit implements --ignored=matching with --untracked-files=all.
The following commit will implement --ignored=matching with
--untracked=files=normal.
As an example of where this flexibility could be useful is that our
application (Visual Studio) runs the status command and presents the
output. It shows all untracked files individually (e.g. using the
'--untracked-files==all' option), and would like to know about which
paths are ignored. It uses information about ignored paths to make
decisions about when the status result might have changed.
Additionally, many projects place build output into directories inside
a repository's working directory (e.g. in "bin/" and "obj/"
directories). Normal usage is to explicitly ignore these 2 directory
names in the .gitignore file (rather than or in addition to the *.obj
pattern).If an application could know that these directories are
explicitly ignored, it could infer that all contents are ignored as
well and make better informed decisions about files in these
directories. It could infer that any changes under these paths would
not affect the output of status. Additionally, there can be a
significant performance benefit by avoiding scanning through ignored
directories.
When status is set to report matching ignored files, it has the
following behavior. Ignored files and directories that explicitly
match an exclude pattern are reported. If an ignored directory matches
an exclude pattern, then the path of the directory is returned. If a
directory does not match an exclude pattern, but all of its contents
are ignored, then the contained files are reported instead of the
directory.
Signed-off-by: Jameson Miller <jamill@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-30 17:21:37 +00:00
|
|
|
static int have_option_m;
|
2011-12-18 05:03:22 +00:00
|
|
|
static struct strbuf message = STRBUF_INIT;
|
2007-11-11 17:36:39 +00:00
|
|
|
|
2016-08-05 22:00:27 +00:00
|
|
|
static enum wt_status_format status_format = STATUS_FORMAT_UNSPECIFIED;
|
2013-06-24 18:41:40 +00:00
|
|
|
|
2021-03-23 13:55:57 +00:00
|
|
|
static int opt_pass_trailer(const struct option *opt, const char *arg, int unset)
|
|
|
|
{
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
|
commit: avoid writing to global in option callback
The callback function for --trailer writes directly to the global
trailer_args and ignores opt->value completely. This is OK, since that's
where we expect to find the value. But it does mean the option
declaration isn't as clear. E.g., we have:
OPT_BOOL(0, "reset-author", &renew_authorship, ...),
OPT_CALLBACK_F(0, "trailer", NULL, ..., opt_pass_trailer)
In the first one we can see where the result will be stored, but in the
second, we get only NULL, and you have to go read the callback.
Let's pass &trailer_args, and use it in the callback. As a bonus, this
silences a -Wunused-parameter warning.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-06 13:11:31 +00:00
|
|
|
strvec_pushl(opt->value, "--trailer", arg, NULL);
|
2021-03-23 13:55:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-08-05 22:00:28 +00:00
|
|
|
static int opt_parse_porcelain(const struct option *opt, const char *arg, int unset)
|
|
|
|
{
|
|
|
|
enum wt_status_format *value = (enum wt_status_format *)opt->value;
|
|
|
|
if (unset)
|
|
|
|
*value = STATUS_FORMAT_NONE;
|
|
|
|
else if (!arg)
|
|
|
|
*value = STATUS_FORMAT_PORCELAIN;
|
|
|
|
else if (!strcmp(arg, "v1") || !strcmp(arg, "1"))
|
|
|
|
*value = STATUS_FORMAT_PORCELAIN;
|
2016-08-11 14:45:57 +00:00
|
|
|
else if (!strcmp(arg, "v2") || !strcmp(arg, "2"))
|
|
|
|
*value = STATUS_FORMAT_PORCELAIN_V2;
|
2016-08-05 22:00:28 +00:00
|
|
|
else
|
|
|
|
die("unsupported porcelain version '%s'", arg);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2009-09-05 08:59:56 +00:00
|
|
|
|
2007-11-11 17:36:39 +00:00
|
|
|
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct strbuf *buf = opt->value;
|
2013-05-25 21:43:34 +00:00
|
|
|
if (unset) {
|
|
|
|
have_option_m = 0;
|
2007-11-11 17:36:39 +00:00
|
|
|
strbuf_setlen(buf, 0);
|
2013-05-25 21:43:34 +00:00
|
|
|
} else {
|
|
|
|
have_option_m = 1;
|
2013-02-19 04:17:06 +00:00
|
|
|
if (buf->len)
|
|
|
|
strbuf_addch(buf, '\n');
|
2007-11-11 17:36:39 +00:00
|
|
|
strbuf_addstr(buf, arg);
|
2013-02-19 04:17:06 +00:00
|
|
|
strbuf_complete_line(buf);
|
2007-11-11 17:36:39 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2018-05-11 15:38:58 +00:00
|
|
|
static int opt_parse_rename_score(const struct option *opt, const char *arg, int unset)
|
|
|
|
{
|
|
|
|
const char **value = opt->value;
|
assert NOARG/NONEG behavior of parse-options callbacks
When we define a parse-options callback, the flags we put in the option
struct must match what the callback expects. For example, a callback
which does not handle the "unset" parameter should only be used with
PARSE_OPT_NONEG. But since the callback and the option struct are not
defined next to each other, it's easy to get this wrong (as earlier
patches in this series show).
Fortunately, the compiler can help us here: compiling with
-Wunused-parameters can show us which callbacks ignore their "unset"
parameters (and likewise, ones that ignore "arg" expect to be triggered
with PARSE_OPT_NOARG).
But after we've inspected a callback and determined that all of its
callers use the right flags, what do we do next? We'd like to silence
the compiler warning, but do so in a way that will catch any wrong calls
in the future.
We can do that by actually checking those variables and asserting that
they match our expectations. Because this is such a common pattern,
we'll introduce some helper macros. The resulting messages aren't
as descriptive as we could make them, but the file/line information from
BUG() is enough to identify the problem (and anyway, the point is that
these should never be seen).
Each of the annotated callbacks in this patch triggers
-Wunused-parameters, and was manually inspected to make sure all callers
use the correct options (so none of these BUGs should be triggerable).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-05 06:45:42 +00:00
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
|
2018-05-11 15:38:58 +00:00
|
|
|
if (arg != NULL && *arg == '=')
|
|
|
|
arg = arg + 1;
|
|
|
|
|
|
|
|
*value = arg;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-02-20 04:12:29 +00:00
|
|
|
static void determine_whence(struct wt_status *s)
|
|
|
|
{
|
2018-05-17 22:51:51 +00:00
|
|
|
if (file_exists(git_path_merge_head(the_repository)))
|
2011-02-20 04:12:29 +00:00
|
|
|
whence = FROM_MERGE;
|
2019-12-06 16:06:11 +00:00
|
|
|
else if (!sequencer_determine_whence(the_repository, &whence))
|
2011-02-20 04:12:29 +00:00
|
|
|
whence = FROM_COMMIT;
|
|
|
|
if (s)
|
|
|
|
s->whence = whence;
|
|
|
|
}
|
|
|
|
|
2013-09-12 10:50:04 +00:00
|
|
|
static void status_init_config(struct wt_status *s, config_fn_t fn)
|
|
|
|
{
|
2018-11-10 05:48:49 +00:00
|
|
|
wt_status_prepare(the_repository, s);
|
2018-05-04 11:12:15 +00:00
|
|
|
init_diff_ui_defaults();
|
2013-09-12 10:50:04 +00:00
|
|
|
git_config(fn, s);
|
|
|
|
determine_whence(s);
|
2021-08-23 10:44:00 +00:00
|
|
|
s->hints = advice_enabled(ADVICE_STATUS_HINTS); /* must come after git_config() */
|
2013-09-12 10:50:04 +00:00
|
|
|
}
|
|
|
|
|
2007-11-18 09:52:55 +00:00
|
|
|
static void rollback_index_files(void)
|
|
|
|
{
|
|
|
|
switch (commit_style) {
|
|
|
|
case COMMIT_AS_IS:
|
|
|
|
break; /* nothing to do */
|
|
|
|
case COMMIT_NORMAL:
|
|
|
|
rollback_lock_file(&index_lock);
|
|
|
|
break;
|
|
|
|
case COMMIT_PARTIAL:
|
|
|
|
rollback_lock_file(&index_lock);
|
|
|
|
rollback_lock_file(&false_lock);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-01-23 17:21:22 +00:00
|
|
|
static int commit_index_files(void)
|
2007-11-18 09:52:55 +00:00
|
|
|
{
|
2008-01-23 17:21:22 +00:00
|
|
|
int err = 0;
|
|
|
|
|
2007-11-18 09:52:55 +00:00
|
|
|
switch (commit_style) {
|
|
|
|
case COMMIT_AS_IS:
|
|
|
|
break; /* nothing to do */
|
|
|
|
case COMMIT_NORMAL:
|
2008-01-23 17:21:22 +00:00
|
|
|
err = commit_lock_file(&index_lock);
|
2007-11-18 09:52:55 +00:00
|
|
|
break;
|
|
|
|
case COMMIT_PARTIAL:
|
2008-01-23 17:21:22 +00:00
|
|
|
err = commit_lock_file(&index_lock);
|
2007-11-18 09:52:55 +00:00
|
|
|
rollback_lock_file(&false_lock);
|
|
|
|
break;
|
|
|
|
}
|
2008-01-23 17:21:22 +00:00
|
|
|
|
|
|
|
return err;
|
2007-11-18 09:52:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Take a union of paths in the index and the named tree (typically, "HEAD"),
|
|
|
|
* and return the paths that match the given pattern in list.
|
|
|
|
*/
|
2008-07-21 18:03:49 +00:00
|
|
|
static int list_paths(struct string_list *list, const char *with_tree,
|
2019-03-20 08:15:48 +00:00
|
|
|
const struct pathspec *pattern)
|
2007-11-18 09:52:55 +00:00
|
|
|
{
|
2015-03-21 00:28:07 +00:00
|
|
|
int i, ret;
|
2007-11-18 09:52:55 +00:00
|
|
|
char *m;
|
|
|
|
|
2013-07-14 08:35:53 +00:00
|
|
|
if (!pattern->nr)
|
commit: fix "--amend --only" with no pathspec
When we do not have any pathspec, we typically disallow an
explicit "--only", because it makes no sense (your commit
would, by definition, be empty). But since 6a74642
(git-commit --amend: two fixes., 2006-04-20), we have
allowed "--amend --only" with the intent that it would amend
the commit, ignoring any contents staged in the index.
However, while that commit allowed the combination, we never
actually implemented the logic to make it work. The current
code notices that we have no pathspec and assumes we want to
do an as-is commit (i.e., the "--only" is ignored).
Instead, we must make sure to follow the partial-commit
code-path. We also need to tweak the list_paths function to
handle a NULL pathspec.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-10 20:40:29 +00:00
|
|
|
return 0;
|
|
|
|
|
2013-07-14 08:35:53 +00:00
|
|
|
m = xcalloc(1, pattern->nr);
|
2007-11-18 09:52:55 +00:00
|
|
|
|
2011-07-30 17:13:47 +00:00
|
|
|
if (with_tree) {
|
2011-09-04 10:42:01 +00:00
|
|
|
char *max_prefix = common_prefix(pattern);
|
2018-04-03 17:57:45 +00:00
|
|
|
overlay_tree_on_index(&the_index, with_tree, max_prefix);
|
2011-09-04 10:41:59 +00:00
|
|
|
free(max_prefix);
|
2011-07-30 17:13:47 +00:00
|
|
|
}
|
2007-11-18 09:52:55 +00:00
|
|
|
|
2021-04-01 01:49:45 +00:00
|
|
|
/* TODO: audit for interaction with sparse-index. */
|
|
|
|
ensure_full_index(&the_index);
|
2022-11-19 13:07:34 +00:00
|
|
|
for (i = 0; i < the_index.cache_nr; i++) {
|
|
|
|
const struct cache_entry *ce = the_index.cache[i];
|
2009-12-14 11:43:59 +00:00
|
|
|
struct string_list_item *item;
|
|
|
|
|
2008-01-15 00:03:17 +00:00
|
|
|
if (ce->ce_flags & CE_UPDATE)
|
2008-01-14 21:54:24 +00:00
|
|
|
continue;
|
2018-08-13 16:14:22 +00:00
|
|
|
if (!ce_path_match(&the_index, ce, pattern, m))
|
2007-11-18 09:52:55 +00:00
|
|
|
continue;
|
2010-06-25 23:41:35 +00:00
|
|
|
item = string_list_insert(list, ce->name);
|
2009-12-14 11:43:59 +00:00
|
|
|
if (ce_skip_worktree(ce))
|
|
|
|
item->util = item; /* better a valid pointer than a fake one */
|
2007-11-18 09:52:55 +00:00
|
|
|
}
|
|
|
|
|
2019-03-20 08:15:48 +00:00
|
|
|
ret = report_path_error(m, pattern);
|
2015-03-21 00:28:07 +00:00
|
|
|
free(m);
|
|
|
|
return ret;
|
2007-11-18 09:52:55 +00:00
|
|
|
}
|
|
|
|
|
2008-07-21 18:03:49 +00:00
|
|
|
static void add_remove_files(struct string_list *list)
|
2007-11-18 09:52:55 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < list->nr; i++) {
|
2008-05-09 16:11:43 +00:00
|
|
|
struct stat st;
|
2008-07-21 18:03:49 +00:00
|
|
|
struct string_list_item *p = &(list->items[i]);
|
2008-05-09 16:11:43 +00:00
|
|
|
|
2009-12-14 11:43:59 +00:00
|
|
|
/* p->util is skip-worktree */
|
|
|
|
if (p->util)
|
2009-08-20 13:46:58 +00:00
|
|
|
continue;
|
2008-05-09 16:11:43 +00:00
|
|
|
|
2008-07-21 18:03:49 +00:00
|
|
|
if (!lstat(p->string, &st)) {
|
2022-11-19 13:07:30 +00:00
|
|
|
if (add_to_index(&the_index, p->string, &st, 0))
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("updating files failed"));
|
2008-05-12 17:57:45 +00:00
|
|
|
} else
|
2022-11-19 13:07:33 +00:00
|
|
|
remove_file_from_index(&the_index, p->string);
|
2007-11-18 09:52:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-19 18:58:18 +00:00
|
|
|
static void create_base_index(const struct commit *current_head)
|
2008-01-13 08:30:56 +00:00
|
|
|
{
|
|
|
|
struct tree *tree;
|
|
|
|
struct unpack_trees_options opts;
|
|
|
|
struct tree_desc t;
|
|
|
|
|
2011-08-19 18:58:18 +00:00
|
|
|
if (!current_head) {
|
2022-11-19 13:07:38 +00:00
|
|
|
discard_index(&the_index);
|
2008-01-13 08:30:56 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
memset(&opts, 0, sizeof(opts));
|
|
|
|
opts.head_idx = 1;
|
|
|
|
opts.index_only = 1;
|
|
|
|
opts.merge = 1;
|
2008-03-07 02:12:28 +00:00
|
|
|
opts.src_index = &the_index;
|
|
|
|
opts.dst_index = &the_index;
|
2008-01-13 08:30:56 +00:00
|
|
|
|
|
|
|
opts.fn = oneway_merge;
|
2017-05-06 22:10:37 +00:00
|
|
|
tree = parse_tree_indirect(¤t_head->object.oid);
|
2008-01-13 08:30:56 +00:00
|
|
|
if (!tree)
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("failed to unpack HEAD tree object"));
|
2008-01-13 08:30:56 +00:00
|
|
|
parse_tree(tree);
|
|
|
|
init_tree_desc(&t, tree->buffer, tree->size);
|
2008-02-07 16:39:48 +00:00
|
|
|
if (unpack_trees(1, &t, &opts))
|
|
|
|
exit(128); /* We've already reported the error, finish dying */
|
2008-01-13 08:30:56 +00:00
|
|
|
}
|
|
|
|
|
Be more user-friendly when refusing to do something because of conflict.
Various commands refuse to run in the presence of conflicts (commit,
merge, pull, cherry-pick/revert). They all used to provide rough, and
inconsistant error messages.
A new variable advice.resolveconflict is introduced, and allows more
verbose messages, pointing the user to the appropriate solution.
For commit, the error message used to look like this:
$ git commit
foo.txt: needs merge
foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
error: Error building trees
The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
option to make the output more consistant with the other porcelain
commands, and catch the error in return, to stop with a clean error
message. The next lines were displayed by a call to cache_tree_update(),
which is not reached anymore if we noticed the conflict.
The new output looks like:
U foo.txt
fatal: 'commit' is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>' as
appropriate to mark resolution and make a commit, or use 'git commit -a'.
Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
exists instead of waiting for merge to complain.
The behavior of merge and the test-case are slightly modified to reflect
the usual flow: start with conflicts, fix them, and afterwards get rid of
MERGE_HEAD, with different error messages at each stage.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12 09:54:44 +00:00
|
|
|
static void refresh_cache_or_die(int refresh_flags)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* refresh_flags contains REFRESH_QUIET, so the only errors
|
|
|
|
* are for unmerged entries.
|
|
|
|
*/
|
2022-11-19 13:07:38 +00:00
|
|
|
if (refresh_index(&the_index, refresh_flags | REFRESH_IN_PORCELAIN, NULL, NULL, NULL))
|
Be more user-friendly when refusing to do something because of conflict.
Various commands refuse to run in the presence of conflicts (commit,
merge, pull, cherry-pick/revert). They all used to provide rough, and
inconsistant error messages.
A new variable advice.resolveconflict is introduced, and allows more
verbose messages, pointing the user to the appropriate solution.
For commit, the error message used to look like this:
$ git commit
foo.txt: needs merge
foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
error: Error building trees
The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
option to make the output more consistant with the other porcelain
commands, and catch the error in return, to stop with a clean error
message. The next lines were displayed by a call to cache_tree_update(),
which is not reached anymore if we noticed the conflict.
The new output looks like:
U foo.txt
fatal: 'commit' is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>' as
appropriate to mark resolution and make a commit, or use 'git commit -a'.
Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
exists instead of waiting for merge to complain.
The behavior of merge and the test-case are slightly modified to reflect
the usual flow: start with conflicts, fix them, and afterwards get rid of
MERGE_HEAD, with different error messages at each stage.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12 09:54:44 +00:00
|
|
|
die_resolve_conflict("commit");
|
|
|
|
}
|
|
|
|
|
2020-09-30 12:28:18 +00:00
|
|
|
static const char *prepare_index(const char **argv, const char *prefix,
|
2014-10-01 10:28:17 +00:00
|
|
|
const struct commit *current_head, int is_status)
|
2007-11-08 16:59:00 +00:00
|
|
|
{
|
2017-09-22 23:34:49 +00:00
|
|
|
struct string_list partial = STRING_LIST_INIT_DUP;
|
2013-07-14 08:35:38 +00:00
|
|
|
struct pathspec pathspec;
|
2009-08-05 06:49:33 +00:00
|
|
|
int refresh_flags = REFRESH_QUIET;
|
2015-08-10 09:47:39 +00:00
|
|
|
const char *ret;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2009-08-05 06:49:33 +00:00
|
|
|
if (is_status)
|
|
|
|
refresh_flags |= REFRESH_UNMERGED;
|
2013-07-14 08:35:38 +00:00
|
|
|
parse_pathspec(&pathspec, 0,
|
|
|
|
PATHSPEC_PREFER_FULL,
|
|
|
|
prefix, argv);
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2019-11-19 16:48:55 +00:00
|
|
|
if (pathspec_from_file) {
|
|
|
|
if (interactive)
|
2022-01-05 20:02:16 +00:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--pathspec-from-file", "--interactive/--patch");
|
2019-11-19 16:48:55 +00:00
|
|
|
|
2019-12-16 15:47:52 +00:00
|
|
|
if (all)
|
2022-01-05 20:02:16 +00:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--pathspec-from-file", "-a");
|
2019-12-16 15:47:52 +00:00
|
|
|
|
2019-11-19 16:48:55 +00:00
|
|
|
if (pathspec.nr)
|
2022-01-05 20:02:24 +00:00
|
|
|
die(_("'%s' and pathspec arguments cannot be used together"), "--pathspec-from-file");
|
2019-11-19 16:48:55 +00:00
|
|
|
|
|
|
|
parse_pathspec_file(&pathspec, 0,
|
|
|
|
PATHSPEC_PREFER_FULL,
|
|
|
|
prefix, pathspec_from_file, pathspec_file_nul);
|
|
|
|
} else if (pathspec_file_nul) {
|
2022-01-05 20:02:19 +00:00
|
|
|
die(_("the option '%s' requires '%s'"), "--pathspec-file-nul", "--pathspec-from-file");
|
2019-11-19 16:48:55 +00:00
|
|
|
}
|
|
|
|
|
2021-03-15 07:54:32 +00:00
|
|
|
if (!pathspec.nr && (also || (only && !allow_empty &&
|
|
|
|
(!amend || (fixup_message && strcmp(fixup_prefix, "amend"))))))
|
2019-11-19 16:48:55 +00:00
|
|
|
die(_("No paths with --include/--only does not make sense."));
|
|
|
|
|
2022-11-19 13:07:38 +00:00
|
|
|
if (repo_read_index_preload(the_repository, &pathspec, 0) < 0)
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("index file corrupt"));
|
2008-11-14 00:36:30 +00:00
|
|
|
|
2011-05-07 05:59:59 +00:00
|
|
|
if (interactive) {
|
2019-12-21 21:57:16 +00:00
|
|
|
char *old_index_env = NULL, *old_repo_index_file;
|
2022-11-19 13:07:38 +00:00
|
|
|
repo_hold_locked_index(the_repository, &index_lock,
|
|
|
|
LOCK_DIE_ON_ERROR);
|
2011-05-07 05:59:59 +00:00
|
|
|
|
|
|
|
refresh_cache_or_die(refresh_flags);
|
|
|
|
|
read-cache: drop explicit `CLOSE_LOCK`-flag
`write_locked_index()` takes two flags: `COMMIT_LOCK` and `CLOSE_LOCK`.
At most one is allowed. But it is also possible to use no flag, i.e.,
`0`. But when `write_locked_index()` calls `do_write_index()`, the
temporary file, a.k.a. the lockfile, will be closed. So passing `0` is
effectively the same as `CLOSE_LOCK`, which seems like a bug.
We might feel tempted to restructure the code in order to close the file
later, or conditionally. It also feels a bit unfortunate that we simply
"happen" to close the lock by way of an implementation detail of
lockfiles. But note that we need to close the temporary file before
`stat`-ing it, at least on Windows. See 9f41c7a6b (read-cache: close
index.lock in do_write_index, 2017-04-26).
Drop `CLOSE_LOCK` and make it explicit that `write_locked_index()`
always closes the lock. Whether it is also committed is governed by the
remaining flag, `COMMIT_LOCK`.
This means we neither have nor suggest that we have a mode to write the
index and leave the file open. Whatever extra contents we might
eventually want to write, we should probably write it from within
`write_locked_index()` itself anyway.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-06 20:12:12 +00:00
|
|
|
if (write_locked_index(&the_index, &index_lock, 0))
|
2011-05-07 05:59:59 +00:00
|
|
|
die(_("unable to create temporary index"));
|
|
|
|
|
2019-12-21 21:57:16 +00:00
|
|
|
old_repo_index_file = the_repository->index_file;
|
|
|
|
the_repository->index_file =
|
|
|
|
(char *)get_lock_file_path(&index_lock);
|
2019-01-11 22:15:40 +00:00
|
|
|
old_index_env = xstrdup_or_null(getenv(INDEX_ENVIRONMENT));
|
2019-12-21 21:57:16 +00:00
|
|
|
setenv(INDEX_ENVIRONMENT, the_repository->index_file, 1);
|
2011-05-07 05:59:59 +00:00
|
|
|
|
2020-09-30 12:28:18 +00:00
|
|
|
if (interactive_add(argv, prefix, patch_interactive) != 0)
|
2011-05-07 05:59:59 +00:00
|
|
|
die(_("interactive add failed"));
|
|
|
|
|
2019-12-21 21:57:16 +00:00
|
|
|
the_repository->index_file = old_repo_index_file;
|
2011-05-07 05:59:59 +00:00
|
|
|
if (old_index_env && *old_index_env)
|
|
|
|
setenv(INDEX_ENVIRONMENT, old_index_env, 1);
|
|
|
|
else
|
|
|
|
unsetenv(INDEX_ENVIRONMENT);
|
2019-01-11 22:15:40 +00:00
|
|
|
FREE_AND_NULL(old_index_env);
|
2011-05-07 05:59:59 +00:00
|
|
|
|
2022-11-19 13:07:38 +00:00
|
|
|
discard_index(&the_index);
|
|
|
|
read_index_from(&the_index, get_lock_file_path(&index_lock),
|
|
|
|
get_git_dir());
|
2023-02-10 10:28:38 +00:00
|
|
|
if (cache_tree_update(&the_index, WRITE_TREE_SILENT) == 0) {
|
2014-09-11 17:33:32 +00:00
|
|
|
if (reopen_lock_file(&index_lock) < 0)
|
2014-07-13 20:28:19 +00:00
|
|
|
die(_("unable to write index file"));
|
read-cache: drop explicit `CLOSE_LOCK`-flag
`write_locked_index()` takes two flags: `COMMIT_LOCK` and `CLOSE_LOCK`.
At most one is allowed. But it is also possible to use no flag, i.e.,
`0`. But when `write_locked_index()` calls `do_write_index()`, the
temporary file, a.k.a. the lockfile, will be closed. So passing `0` is
effectively the same as `CLOSE_LOCK`, which seems like a bug.
We might feel tempted to restructure the code in order to close the file
later, or conditionally. It also feels a bit unfortunate that we simply
"happen" to close the lock by way of an implementation detail of
lockfiles. But note that we need to close the temporary file before
`stat`-ing it, at least on Windows. See 9f41c7a6b (read-cache: close
index.lock in do_write_index, 2017-04-26).
Drop `CLOSE_LOCK` and make it explicit that `write_locked_index()`
always closes the lock. Whether it is also committed is governed by the
remaining flag, `COMMIT_LOCK`.
This means we neither have nor suggest that we have a mode to write the
index and leave the file open. Whatever extra contents we might
eventually want to write, we should probably write it from within
`write_locked_index()` itself anyway.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-06 20:12:12 +00:00
|
|
|
if (write_locked_index(&the_index, &index_lock, 0))
|
2014-09-11 17:33:32 +00:00
|
|
|
die(_("unable to update temporary index"));
|
2014-07-13 20:28:19 +00:00
|
|
|
} else
|
|
|
|
warning(_("Failed to update main cache tree"));
|
2011-05-07 05:59:59 +00:00
|
|
|
|
|
|
|
commit_style = COMMIT_NORMAL;
|
2017-09-22 23:34:49 +00:00
|
|
|
ret = get_lock_file_path(&index_lock);
|
|
|
|
goto out;
|
2011-05-07 05:59:59 +00:00
|
|
|
}
|
|
|
|
|
2007-11-18 09:52:55 +00:00
|
|
|
/*
|
|
|
|
* Non partial, non as-is commit.
|
|
|
|
*
|
|
|
|
* (1) get the real index;
|
|
|
|
* (2) update the_index as necessary;
|
|
|
|
* (3) write the_index out to the real index (still locked);
|
|
|
|
* (4) return the name of the locked index file.
|
|
|
|
*
|
|
|
|
* The caller should run hooks on the locked real index, and
|
|
|
|
* (A) if all goes well, commit the real index;
|
|
|
|
* (B) on failure, rollback the real index.
|
|
|
|
*/
|
2013-07-14 08:35:38 +00:00
|
|
|
if (all || (also && pathspec.nr)) {
|
2022-11-19 13:07:38 +00:00
|
|
|
repo_hold_locked_index(the_repository, &index_lock,
|
|
|
|
LOCK_DIE_ON_ERROR);
|
2023-05-16 06:33:46 +00:00
|
|
|
add_files_to_cache(the_repository, also ? prefix : NULL,
|
|
|
|
&pathspec, 0, 0);
|
Be more user-friendly when refusing to do something because of conflict.
Various commands refuse to run in the presence of conflicts (commit,
merge, pull, cherry-pick/revert). They all used to provide rough, and
inconsistant error messages.
A new variable advice.resolveconflict is introduced, and allows more
verbose messages, pointing the user to the appropriate solution.
For commit, the error message used to look like this:
$ git commit
foo.txt: needs merge
foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
error: Error building trees
The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
option to make the output more consistant with the other porcelain
commands, and catch the error in return, to stop with a clean error
message. The next lines were displayed by a call to cache_tree_update(),
which is not reached anymore if we noticed the conflict.
The new output looks like:
U foo.txt
fatal: 'commit' is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>' as
appropriate to mark resolution and make a commit, or use 'git commit -a'.
Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
exists instead of waiting for merge to complain.
The behavior of merge and the test-case are slightly modified to reflect
the usual flow: start with conflicts, fix them, and afterwards get rid of
MERGE_HEAD, with different error messages at each stage.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12 09:54:44 +00:00
|
|
|
refresh_cache_or_die(refresh_flags);
|
2023-02-10 10:28:38 +00:00
|
|
|
cache_tree_update(&the_index, WRITE_TREE_SILENT);
|
read-cache: drop explicit `CLOSE_LOCK`-flag
`write_locked_index()` takes two flags: `COMMIT_LOCK` and `CLOSE_LOCK`.
At most one is allowed. But it is also possible to use no flag, i.e.,
`0`. But when `write_locked_index()` calls `do_write_index()`, the
temporary file, a.k.a. the lockfile, will be closed. So passing `0` is
effectively the same as `CLOSE_LOCK`, which seems like a bug.
We might feel tempted to restructure the code in order to close the file
later, or conditionally. It also feels a bit unfortunate that we simply
"happen" to close the lock by way of an implementation detail of
lockfiles. But note that we need to close the temporary file before
`stat`-ing it, at least on Windows. See 9f41c7a6b (read-cache: close
index.lock in do_write_index, 2017-04-26).
Drop `CLOSE_LOCK` and make it explicit that `write_locked_index()`
always closes the lock. Whether it is also committed is governed by the
remaining flag, `COMMIT_LOCK`.
This means we neither have nor suggest that we have a mode to write the
index and leave the file open. Whatever extra contents we might
eventually want to write, we should probably write it from within
`write_locked_index()` itself anyway.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-06 20:12:12 +00:00
|
|
|
if (write_locked_index(&the_index, &index_lock, 0))
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("unable to write new_index file"));
|
2007-11-18 09:52:55 +00:00
|
|
|
commit_style = COMMIT_NORMAL;
|
2017-09-22 23:34:49 +00:00
|
|
|
ret = get_lock_file_path(&index_lock);
|
|
|
|
goto out;
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
|
|
|
|
2007-11-18 09:52:55 +00:00
|
|
|
/*
|
|
|
|
* As-is commit.
|
|
|
|
*
|
|
|
|
* (1) return the name of the real index file.
|
|
|
|
*
|
2010-04-02 12:27:18 +00:00
|
|
|
* The caller should run hooks on the real index,
|
|
|
|
* and create commit from the_index.
|
2007-11-18 09:52:55 +00:00
|
|
|
* We still need to refresh the index here.
|
|
|
|
*/
|
2013-07-14 08:35:38 +00:00
|
|
|
if (!only && !pathspec.nr) {
|
2022-11-19 13:07:38 +00:00
|
|
|
repo_hold_locked_index(the_repository, &index_lock,
|
|
|
|
LOCK_DIE_ON_ERROR);
|
Be more user-friendly when refusing to do something because of conflict.
Various commands refuse to run in the presence of conflicts (commit,
merge, pull, cherry-pick/revert). They all used to provide rough, and
inconsistant error messages.
A new variable advice.resolveconflict is introduced, and allows more
verbose messages, pointing the user to the appropriate solution.
For commit, the error message used to look like this:
$ git commit
foo.txt: needs merge
foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
error: Error building trees
The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
option to make the output more consistant with the other porcelain
commands, and catch the error in return, to stop with a clean error
message. The next lines were displayed by a call to cache_tree_update(),
which is not reached anymore if we noticed the conflict.
The new output looks like:
U foo.txt
fatal: 'commit' is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>' as
appropriate to mark resolution and make a commit, or use 'git commit -a'.
Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
exists instead of waiting for merge to complain.
The behavior of merge and the test-case are slightly modified to reflect
the usual flow: start with conflicts, fix them, and afterwards get rid of
MERGE_HEAD, with different error messages at each stage.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12 09:54:44 +00:00
|
|
|
refresh_cache_or_die(refresh_flags);
|
2022-11-19 13:07:34 +00:00
|
|
|
if (the_index.cache_changed
|
|
|
|
|| !cache_tree_fully_valid(the_index.cache_tree))
|
2023-02-10 10:28:38 +00:00
|
|
|
cache_tree_update(&the_index, WRITE_TREE_SILENT);
|
2018-03-01 20:40:20 +00:00
|
|
|
if (write_locked_index(&the_index, &index_lock,
|
|
|
|
COMMIT_LOCK | SKIP_IF_UNCHANGED))
|
|
|
|
die(_("unable to write new_index file"));
|
2007-11-18 09:52:55 +00:00
|
|
|
commit_style = COMMIT_AS_IS;
|
2017-09-22 23:34:49 +00:00
|
|
|
ret = get_index_file();
|
|
|
|
goto out;
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
|
|
|
|
2007-11-18 09:52:55 +00:00
|
|
|
/*
|
|
|
|
* A partial commit.
|
|
|
|
*
|
|
|
|
* (0) find the set of affected paths;
|
|
|
|
* (1) get lock on the real index file;
|
|
|
|
* (2) update the_index with the given paths;
|
|
|
|
* (3) write the_index out to the real index (still locked);
|
|
|
|
* (4) get lock on the false index file;
|
|
|
|
* (5) reset the_index from HEAD;
|
|
|
|
* (6) update the_index the same way as (2);
|
|
|
|
* (7) write the_index out to the false index file;
|
|
|
|
* (8) return the name of the false index file (still locked);
|
|
|
|
*
|
|
|
|
* The caller should run hooks on the locked false index, and
|
|
|
|
* create commit from it. Then
|
|
|
|
* (A) if all goes well, commit the real index;
|
|
|
|
* (B) on failure, rollback the real index;
|
|
|
|
* In either case, rollback the false index.
|
|
|
|
*/
|
|
|
|
commit_style = COMMIT_PARTIAL;
|
|
|
|
|
2012-04-30 15:33:13 +00:00
|
|
|
if (whence != FROM_COMMIT) {
|
|
|
|
if (whence == FROM_MERGE)
|
|
|
|
die(_("cannot do a partial commit during a merge."));
|
2019-12-06 16:06:10 +00:00
|
|
|
else if (is_from_cherry_pick(whence))
|
2012-04-30 15:33:13 +00:00
|
|
|
die(_("cannot do a partial commit during a cherry-pick."));
|
2019-12-06 16:06:12 +00:00
|
|
|
else if (is_from_rebase(whence))
|
|
|
|
die(_("cannot do a partial commit during a rebase."));
|
2012-04-30 15:33:13 +00:00
|
|
|
}
|
2007-11-18 09:52:55 +00:00
|
|
|
|
2019-03-20 08:15:48 +00:00
|
|
|
if (list_paths(&partial, !current_head ? NULL : "HEAD", &pathspec))
|
2007-11-18 09:52:55 +00:00
|
|
|
exit(1);
|
|
|
|
|
2022-11-19 13:07:38 +00:00
|
|
|
discard_index(&the_index);
|
|
|
|
if (repo_read_index(the_repository) < 0)
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("cannot read the index"));
|
2007-11-18 09:52:55 +00:00
|
|
|
|
2022-11-19 13:07:38 +00:00
|
|
|
repo_hold_locked_index(the_repository, &index_lock, LOCK_DIE_ON_ERROR);
|
2007-11-18 09:52:55 +00:00
|
|
|
add_remove_files(&partial);
|
2022-11-19 13:07:38 +00:00
|
|
|
refresh_index(&the_index, REFRESH_QUIET, NULL, NULL, NULL);
|
2023-02-10 10:28:38 +00:00
|
|
|
cache_tree_update(&the_index, WRITE_TREE_SILENT);
|
read-cache: drop explicit `CLOSE_LOCK`-flag
`write_locked_index()` takes two flags: `COMMIT_LOCK` and `CLOSE_LOCK`.
At most one is allowed. But it is also possible to use no flag, i.e.,
`0`. But when `write_locked_index()` calls `do_write_index()`, the
temporary file, a.k.a. the lockfile, will be closed. So passing `0` is
effectively the same as `CLOSE_LOCK`, which seems like a bug.
We might feel tempted to restructure the code in order to close the file
later, or conditionally. It also feels a bit unfortunate that we simply
"happen" to close the lock by way of an implementation detail of
lockfiles. But note that we need to close the temporary file before
`stat`-ing it, at least on Windows. See 9f41c7a6b (read-cache: close
index.lock in do_write_index, 2017-04-26).
Drop `CLOSE_LOCK` and make it explicit that `write_locked_index()`
always closes the lock. Whether it is also committed is governed by the
remaining flag, `COMMIT_LOCK`.
This means we neither have nor suggest that we have a mode to write the
index and leave the file open. Whatever extra contents we might
eventually want to write, we should probably write it from within
`write_locked_index()` itself anyway.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-06 20:12:12 +00:00
|
|
|
if (write_locked_index(&the_index, &index_lock, 0))
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("unable to write new_index file"));
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2014-06-13 12:19:23 +00:00
|
|
|
hold_lock_file_for_update(&false_lock,
|
|
|
|
git_path("next-index-%"PRIuMAX,
|
|
|
|
(uintmax_t) getpid()),
|
|
|
|
LOCK_DIE_ON_ERROR);
|
2008-01-13 08:30:56 +00:00
|
|
|
|
2011-08-19 18:58:18 +00:00
|
|
|
create_base_index(current_head);
|
2007-11-18 09:52:55 +00:00
|
|
|
add_remove_files(&partial);
|
2022-11-19 13:07:38 +00:00
|
|
|
refresh_index(&the_index, REFRESH_QUIET, NULL, NULL, NULL);
|
2007-11-08 16:59:00 +00:00
|
|
|
|
read-cache: drop explicit `CLOSE_LOCK`-flag
`write_locked_index()` takes two flags: `COMMIT_LOCK` and `CLOSE_LOCK`.
At most one is allowed. But it is also possible to use no flag, i.e.,
`0`. But when `write_locked_index()` calls `do_write_index()`, the
temporary file, a.k.a. the lockfile, will be closed. So passing `0` is
effectively the same as `CLOSE_LOCK`, which seems like a bug.
We might feel tempted to restructure the code in order to close the file
later, or conditionally. It also feels a bit unfortunate that we simply
"happen" to close the lock by way of an implementation detail of
lockfiles. But note that we need to close the temporary file before
`stat`-ing it, at least on Windows. See 9f41c7a6b (read-cache: close
index.lock in do_write_index, 2017-04-26).
Drop `CLOSE_LOCK` and make it explicit that `write_locked_index()`
always closes the lock. Whether it is also committed is governed by the
remaining flag, `COMMIT_LOCK`.
This means we neither have nor suggest that we have a mode to write the
index and leave the file open. Whatever extra contents we might
eventually want to write, we should probably write it from within
`write_locked_index()` itself anyway.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-06 20:12:12 +00:00
|
|
|
if (write_locked_index(&the_index, &false_lock, 0))
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("unable to write temporary index file"));
|
2008-02-14 17:18:23 +00:00
|
|
|
|
2022-11-19 13:07:38 +00:00
|
|
|
discard_index(&the_index);
|
2015-08-10 09:47:39 +00:00
|
|
|
ret = get_lock_file_path(&false_lock);
|
2022-11-19 13:07:38 +00:00
|
|
|
read_index_from(&the_index, ret, get_git_dir());
|
2017-09-22 23:34:49 +00:00
|
|
|
out:
|
|
|
|
string_list_clear(&partial, 0);
|
|
|
|
clear_pathspec(&pathspec);
|
2015-08-10 09:47:39 +00:00
|
|
|
return ret;
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
|
|
|
|
2009-08-10 04:59:30 +00:00
|
|
|
static int run_status(FILE *fp, const char *index_file, const char *prefix, int nowarn,
|
|
|
|
struct wt_status *s)
|
2007-11-08 16:59:00 +00:00
|
|
|
{
|
2017-02-20 00:10:14 +00:00
|
|
|
struct object_id oid;
|
2009-08-08 06:31:57 +00:00
|
|
|
|
2009-08-10 04:59:30 +00:00
|
|
|
if (s->relative_paths)
|
|
|
|
s->prefix = prefix;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
|
|
|
if (amend) {
|
2009-08-10 04:59:30 +00:00
|
|
|
s->amend = 1;
|
|
|
|
s->reference = "HEAD^1";
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
2009-08-10 04:59:30 +00:00
|
|
|
s->verbose = verbose;
|
|
|
|
s->index_file = index_file;
|
|
|
|
s->fp = fp;
|
|
|
|
s->nowarn = nowarn;
|
2023-03-28 13:58:46 +00:00
|
|
|
s->is_initial = repo_get_oid(the_repository, s->reference, &oid) ? 1 : 0;
|
2016-08-11 14:45:59 +00:00
|
|
|
if (!s->is_initial)
|
2019-08-18 20:04:21 +00:00
|
|
|
oidcpy(&s->oid_commit, &oid);
|
2016-08-05 22:00:27 +00:00
|
|
|
s->status_format = status_format;
|
|
|
|
s->ignore_submodule_arg = ignore_submodule_arg;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2009-08-08 06:31:57 +00:00
|
|
|
wt_status_collect(s);
|
2016-08-05 22:00:27 +00:00
|
|
|
wt_status_print(s);
|
2018-09-30 14:12:45 +00:00
|
|
|
wt_status_collect_free_buffers(s);
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2018-09-06 00:53:27 +00:00
|
|
|
return s->committable;
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
|
|
|
|
2011-08-19 18:58:18 +00:00
|
|
|
static int is_a_merge(const struct commit *current_head)
|
2008-02-05 10:01:46 +00:00
|
|
|
{
|
2011-08-19 18:58:18 +00:00
|
|
|
return !!(current_head->parents && current_head->parents->next);
|
2008-02-05 10:01:46 +00:00
|
|
|
}
|
|
|
|
|
commit: loosen ident checks when generating template
When we generate the commit-message template, we try to
report an author or committer ident that will be of interest
to the user: an author that does not match the committer, or
a committer that was auto-configured.
When doing so, if we encounter what we consider to be a
bogus ident, we immediately die. This is a bad idea, because
our use of the idents here is purely informational. Any
ident rules should be enforced elsewhere, because commits
that do not invoke the editor will not even hit this code
path (e.g., "git commit -mfoo" would work, but "git commit"
would not). So at best, we are redundant with other checks,
and at worse, we actively prevent commits that should
otherwise be allowed.
We should therefore do the minimal parsing we can to get a
value and not do any validation (i.e., drop the call to
sane_ident_split()).
In theory we could notice when even our minimal parsing
fails to work, and do the sane thing for each check (e.g.,
if we have an author but can't parse the committer, assume
they are different and print the author). But we can
actually simplify this even further.
We know that the author and committer strings we are parsing
have been generated by us earlier in the program, and
therefore they must be parseable. We could just call
split_ident_line without even checking its return value,
knowing that it will put _something_ in the name/mail
fields. Of course, to protect ourselves against future
changes to the code, it makes sense to turn this into an
assert, so we are not surprised if our assumption fails.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-10 15:42:10 +00:00
|
|
|
static void assert_split_ident(struct ident_split *id, const struct strbuf *buf)
|
|
|
|
{
|
commit: always populate GIT_AUTHOR_* variables
To figure out the author ident for a commit, we call
determine_author_info(). This function collects information
from the environment, other commits (in the case of
"--amend" or "-c/-C"), and the "--author" option. It then
uses fmt_ident to generate the final ident string that goes
into the commit object. fmt_ident is therefore responsible
for any quality or validation checks on what is allowed to
go into a commit.
Before returning, though, we call split_ident_line on the
result, and feed the individual components to hooks via the
GIT_AUTHOR_* variables. Furthermore, we do extra validation
by feeding the split to sane_ident_split(), which is pickier
than fmt_ident (in particular, it will complain about an empty
email field). If this parsing or validation fails, we skip
updating the environment variables.
This is bad, because it means that hooks may silently see a
different ident than what we are putting into the commit. We
should drop the extra sane_ident_split checks entirely, and
take whatever fmt_ident has fed us (and what will go into
the commit object).
If parsing fails, we should actually abort here rather than
continuing (and feeding the hooks bogus data). However,
split_ident_line should never fail here. The ident was just
generated by fmt_ident, so we know that it's sane. We can
use assert_split_ident to double-check this.
Note that we also teach that assertion to check that we
found a date (it always should, but until now, no caller
cared whether we found a date or not). Checking the return
value of sane_ident_split is enough to ensure we have the
name/email pointers set, and checking date_begin is enough
to know that all of the date/tz variables are set.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-10 15:43:42 +00:00
|
|
|
if (split_ident_line(id, buf->buf, buf->len) || !id->date_begin)
|
2018-05-02 09:38:39 +00:00
|
|
|
BUG("unable to parse our own ident: %s", buf->buf);
|
commit: loosen ident checks when generating template
When we generate the commit-message template, we try to
report an author or committer ident that will be of interest
to the user: an author that does not match the committer, or
a committer that was auto-configured.
When doing so, if we encounter what we consider to be a
bogus ident, we immediately die. This is a bad idea, because
our use of the idents here is purely informational. Any
ident rules should be enforced elsewhere, because commits
that do not invoke the editor will not even hit this code
path (e.g., "git commit -mfoo" would work, but "git commit"
would not). So at best, we are redundant with other checks,
and at worse, we actively prevent commits that should
otherwise be allowed.
We should therefore do the minimal parsing we can to get a
value and not do any validation (i.e., drop the call to
sane_ident_split()).
In theory we could notice when even our minimal parsing
fails to work, and do the sane thing for each check (e.g.,
if we have an author but can't parse the committer, assume
they are different and print the author). But we can
actually simplify this even further.
We know that the author and committer strings we are parsing
have been generated by us earlier in the program, and
therefore they must be parseable. We could just call
split_ident_line without even checking its return value,
knowing that it will put _something_ in the name/mail
fields. Of course, to protect ourselves against future
changes to the code, it makes sense to turn this into an
assert, so we are not surprised if our assumption fails.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-10 15:42:10 +00:00
|
|
|
}
|
|
|
|
|
2012-03-11 10:12:10 +00:00
|
|
|
static void export_one(const char *var, const char *s, const char *e, int hack)
|
|
|
|
{
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
if (hack)
|
|
|
|
strbuf_addch(&buf, hack);
|
2019-12-07 11:16:04 +00:00
|
|
|
strbuf_add(&buf, s, e - s);
|
2012-03-11 10:12:10 +00:00
|
|
|
setenv(var, buf.buf, 1);
|
|
|
|
strbuf_release(&buf);
|
|
|
|
}
|
|
|
|
|
2014-08-27 07:57:08 +00:00
|
|
|
static int parse_force_date(const char *in, struct strbuf *out)
|
2014-05-02 01:12:42 +00:00
|
|
|
{
|
2014-08-27 07:57:08 +00:00
|
|
|
strbuf_addch(out, '@');
|
2014-05-02 01:12:42 +00:00
|
|
|
|
2014-08-27 07:57:08 +00:00
|
|
|
if (parse_date(in, out) < 0) {
|
2014-05-02 01:12:42 +00:00
|
|
|
int errors = 0;
|
|
|
|
unsigned long t = approxidate_careful(in, &errors);
|
|
|
|
if (errors)
|
|
|
|
return -1;
|
2014-08-27 07:57:08 +00:00
|
|
|
strbuf_addf(out, "%lu", t);
|
2014-05-02 01:12:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-08-27 07:57:56 +00:00
|
|
|
static void set_ident_var(char **buf, char *val)
|
|
|
|
{
|
|
|
|
free(*buf);
|
|
|
|
*buf = val;
|
|
|
|
}
|
|
|
|
|
2010-12-21 01:00:36 +00:00
|
|
|
static void determine_author_info(struct strbuf *author_ident)
|
2008-05-04 16:04:49 +00:00
|
|
|
{
|
|
|
|
char *name, *email, *date;
|
2012-03-11 10:12:10 +00:00
|
|
|
struct ident_split author;
|
2008-05-04 16:04:49 +00:00
|
|
|
|
2015-01-13 01:58:33 +00:00
|
|
|
name = xstrdup_or_null(getenv("GIT_AUTHOR_NAME"));
|
|
|
|
email = xstrdup_or_null(getenv("GIT_AUTHOR_EMAIL"));
|
|
|
|
date = xstrdup_or_null(getenv("GIT_AUTHOR_DATE"));
|
2008-05-04 16:04:49 +00:00
|
|
|
|
2011-02-20 04:12:29 +00:00
|
|
|
if (author_message) {
|
2014-08-27 07:57:28 +00:00
|
|
|
struct ident_split ident;
|
2012-02-02 21:41:43 +00:00
|
|
|
size_t len;
|
2014-08-27 07:57:28 +00:00
|
|
|
const char *a;
|
2008-05-04 16:04:49 +00:00
|
|
|
|
2014-08-27 07:57:28 +00:00
|
|
|
a = find_commit_header(author_message_buffer, "author", &len);
|
2008-05-04 16:04:49 +00:00
|
|
|
if (!a)
|
2014-08-27 07:57:28 +00:00
|
|
|
die(_("commit '%s' lacks author header"), author_message);
|
|
|
|
if (split_ident_line(&ident, a, len) < 0)
|
|
|
|
die(_("commit '%s' has malformed author line"), author_message);
|
|
|
|
|
2014-08-27 07:57:56 +00:00
|
|
|
set_ident_var(&name, xmemdupz(ident.name_begin, ident.name_end - ident.name_begin));
|
|
|
|
set_ident_var(&email, xmemdupz(ident.mail_begin, ident.mail_end - ident.mail_begin));
|
|
|
|
|
2014-08-27 07:57:28 +00:00
|
|
|
if (ident.date_begin) {
|
2014-08-27 07:57:56 +00:00
|
|
|
struct strbuf date_buf = STRBUF_INIT;
|
2014-08-27 07:57:28 +00:00
|
|
|
strbuf_addch(&date_buf, '@');
|
|
|
|
strbuf_add(&date_buf, ident.date_begin, ident.date_end - ident.date_begin);
|
|
|
|
strbuf_addch(&date_buf, ' ');
|
|
|
|
strbuf_add(&date_buf, ident.tz_begin, ident.tz_end - ident.tz_begin);
|
2014-08-27 07:57:56 +00:00
|
|
|
set_ident_var(&date, strbuf_detach(&date_buf, NULL));
|
2014-08-27 07:57:28 +00:00
|
|
|
}
|
2008-05-04 16:04:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (force_author) {
|
2014-08-27 07:57:28 +00:00
|
|
|
struct ident_split ident;
|
2008-05-04 16:04:49 +00:00
|
|
|
|
2014-08-27 07:57:28 +00:00
|
|
|
if (split_ident_line(&ident, force_author, strlen(force_author)) < 0)
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("malformed --author parameter"));
|
2014-08-27 07:57:56 +00:00
|
|
|
set_ident_var(&name, xmemdupz(ident.name_begin, ident.name_end - ident.name_begin));
|
|
|
|
set_ident_var(&email, xmemdupz(ident.mail_begin, ident.mail_end - ident.mail_begin));
|
2008-05-04 16:04:49 +00:00
|
|
|
}
|
|
|
|
|
2014-05-02 01:12:42 +00:00
|
|
|
if (force_date) {
|
2014-08-27 07:57:56 +00:00
|
|
|
struct strbuf date_buf = STRBUF_INIT;
|
2014-08-27 07:57:08 +00:00
|
|
|
if (parse_force_date(force_date, &date_buf))
|
2014-05-02 01:12:42 +00:00
|
|
|
die(_("invalid date format: %s"), force_date);
|
2014-08-27 07:57:56 +00:00
|
|
|
set_ident_var(&date, strbuf_detach(&date_buf, NULL));
|
2014-05-02 01:12:42 +00:00
|
|
|
}
|
|
|
|
|
2019-02-04 18:48:50 +00:00
|
|
|
strbuf_addstr(author_ident, fmt_ident(name, email, WANT_AUTHOR_IDENT, date,
|
|
|
|
IDENT_STRICT));
|
commit: always populate GIT_AUTHOR_* variables
To figure out the author ident for a commit, we call
determine_author_info(). This function collects information
from the environment, other commits (in the case of
"--amend" or "-c/-C"), and the "--author" option. It then
uses fmt_ident to generate the final ident string that goes
into the commit object. fmt_ident is therefore responsible
for any quality or validation checks on what is allowed to
go into a commit.
Before returning, though, we call split_ident_line on the
result, and feed the individual components to hooks via the
GIT_AUTHOR_* variables. Furthermore, we do extra validation
by feeding the split to sane_ident_split(), which is pickier
than fmt_ident (in particular, it will complain about an empty
email field). If this parsing or validation fails, we skip
updating the environment variables.
This is bad, because it means that hooks may silently see a
different ident than what we are putting into the commit. We
should drop the extra sane_ident_split checks entirely, and
take whatever fmt_ident has fed us (and what will go into
the commit object).
If parsing fails, we should actually abort here rather than
continuing (and feeding the hooks bogus data). However,
split_ident_line should never fail here. The ident was just
generated by fmt_ident, so we know that it's sane. We can
use assert_split_ident to double-check this.
Note that we also teach that assertion to check that we
found a date (it always should, but until now, no caller
cared whether we found a date or not). Checking the return
value of sane_ident_split is enough to ensure we have the
name/email pointers set, and checking date_begin is enough
to know that all of the date/tz variables are set.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-10 15:43:42 +00:00
|
|
|
assert_split_ident(&author, author_ident);
|
|
|
|
export_one("GIT_AUTHOR_NAME", author.name_begin, author.name_end, 0);
|
|
|
|
export_one("GIT_AUTHOR_EMAIL", author.mail_begin, author.mail_end, 0);
|
|
|
|
export_one("GIT_AUTHOR_DATE", author.date_begin, author.tz_end, '@');
|
2014-08-27 07:57:56 +00:00
|
|
|
free(name);
|
|
|
|
free(email);
|
|
|
|
free(date);
|
2008-05-04 16:04:49 +00:00
|
|
|
}
|
|
|
|
|
2014-05-02 01:10:01 +00:00
|
|
|
static int author_date_is_interesting(void)
|
|
|
|
{
|
|
|
|
return author_message || force_date;
|
2010-12-21 01:00:36 +00:00
|
|
|
}
|
|
|
|
|
2014-05-17 01:52:23 +00:00
|
|
|
static void adjust_comment_line_char(const struct strbuf *sb)
|
|
|
|
{
|
|
|
|
char candidates[] = "#;@!$%^&|:";
|
|
|
|
char *candidate;
|
|
|
|
const char *p;
|
|
|
|
|
|
|
|
comment_line_char = candidates[0];
|
|
|
|
if (!memchr(sb->buf, comment_line_char, sb->len))
|
|
|
|
return;
|
|
|
|
|
|
|
|
p = sb->buf;
|
|
|
|
candidate = strchr(candidates, *p);
|
|
|
|
if (candidate)
|
|
|
|
*candidate = ' ';
|
|
|
|
for (p = sb->buf; *p; p++) {
|
|
|
|
if ((p[0] == '\n' || p[0] == '\r') && p[1]) {
|
|
|
|
candidate = strchr(candidates, p[1]);
|
|
|
|
if (candidate)
|
|
|
|
*candidate = ' ';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (p = candidates; *p == ' '; p++)
|
|
|
|
;
|
|
|
|
if (!*p)
|
|
|
|
die(_("unable to select a comment character that is not used\n"
|
|
|
|
"in the current commit message"));
|
|
|
|
comment_line_char = *p;
|
|
|
|
}
|
|
|
|
|
2021-03-15 07:54:32 +00:00
|
|
|
static void prepare_amend_commit(struct commit *commit, struct strbuf *sb,
|
|
|
|
struct pretty_print_context *ctx)
|
|
|
|
{
|
|
|
|
const char *buffer, *subject, *fmt;
|
|
|
|
|
2023-03-28 13:58:48 +00:00
|
|
|
buffer = repo_get_commit_buffer(the_repository, commit, NULL);
|
2021-03-15 07:54:32 +00:00
|
|
|
find_commit_subject(buffer, &subject);
|
|
|
|
/*
|
|
|
|
* If we amend the 'amend!' commit then we don't want to
|
|
|
|
* duplicate the subject line.
|
|
|
|
*/
|
|
|
|
fmt = starts_with(subject, "amend!") ? "%b" : "%B";
|
2023-03-28 13:58:51 +00:00
|
|
|
repo_format_commit_message(the_repository, commit, fmt, sb, ctx);
|
2023-03-28 13:58:48 +00:00
|
|
|
repo_unuse_commit_buffer(the_repository, commit, buffer);
|
2021-03-15 07:54:32 +00:00
|
|
|
}
|
|
|
|
|
2009-08-10 04:59:30 +00:00
|
|
|
static int prepare_to_commit(const char *index_file, const char *prefix,
|
2011-08-19 18:58:18 +00:00
|
|
|
struct commit *current_head,
|
2010-12-21 01:00:36 +00:00
|
|
|
struct wt_status *s,
|
|
|
|
struct strbuf *author_ident)
|
2007-11-08 16:59:00 +00:00
|
|
|
{
|
|
|
|
struct stat statbuf;
|
2010-12-21 01:00:36 +00:00
|
|
|
struct strbuf committer_ident = STRBUF_INIT;
|
2018-09-06 00:53:27 +00:00
|
|
|
int committable;
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2008-02-05 07:04:18 +00:00
|
|
|
const char *hook_arg1 = NULL;
|
|
|
|
const char *hook_arg2 = NULL;
|
2017-11-10 11:09:42 +00:00
|
|
|
int clean_message_contents = (cleanup_mode != COMMIT_MSG_CLEANUP_NONE);
|
2013-09-06 17:43:07 +00:00
|
|
|
int old_display_comment_prefix;
|
2019-04-17 10:23:28 +00:00
|
|
|
int merge_contains_scissors = 0;
|
hooks: fix an obscure TOCTOU "did we just run a hook?" race
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in
680ee550d72 (commit: skip discarding the index if there is no
pre-commit hook, 2017-08-14).
This obscure race condition can occur if we e.g. ran the "pre-commit"
hook and it modified the index, but hook_exists() returns false later
on (e.g., because the hook itself went away, the directory became
unreadable, etc.). Then we won't call discard_cache() when we should
have.
The race condition itself probably doesn't matter, and users would
have been unlikely to run into it in practice. This problem has been
noted on-list when 680ee550d72 was discussed[1], but had not been
fixed.
This change is mainly intended to improve the readability of the code
involved, and to make reasoning about it more straightforward. It
wasn't as obvious what we were trying to do here, but by having an
"invoked_hook" it's clearer that e.g. our discard_cache() is happening
because of the earlier hook execution.
Let's also change this for the push-to-checkout hook. Now instead of
checking if the hook exists and either doing a push to checkout or a
push to deploy we'll always attempt a push to checkout. If the hook
doesn't exist we'll fall back on push to deploy. The same behavior as
before, without the TOCTOU race. See 0855331941b (receive-pack:
support push-to-checkout hook, 2014-12-01) for the introduction of the
previous behavior.
This leaves uses of hook_exists() in two places that matter. The
"reference-transaction" check in refs.c, see 67541597670 (refs:
implement reference transaction hook, 2020-06-19), and the
"prepare-commit-msg" hook, see 66618a50f9c (sequencer: run
'prepare-commit-msg' hook, 2018-01-24).
In both of those cases we're saving ourselves CPU time by not
preparing data for the hook that we'll then do nothing with if we
don't have the hook. So using this "invoked_hook" pattern doesn't make
sense in those cases.
The "reference-transaction" and "prepare-commit-msg" hook also aren't
racy. In those cases we'll skip the hook runs if we race with a new
hook being added, whereas in the TOCTOU races being fixed here we were
incorrectly skipping the required post-hook logic.
1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:33:46 +00:00
|
|
|
int invoked_hook;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2012-03-11 10:12:10 +00:00
|
|
|
/* This checks and barfs if author is badly specified */
|
|
|
|
determine_author_info(author_ident);
|
|
|
|
|
hooks: fix an obscure TOCTOU "did we just run a hook?" race
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in
680ee550d72 (commit: skip discarding the index if there is no
pre-commit hook, 2017-08-14).
This obscure race condition can occur if we e.g. ran the "pre-commit"
hook and it modified the index, but hook_exists() returns false later
on (e.g., because the hook itself went away, the directory became
unreadable, etc.). Then we won't call discard_cache() when we should
have.
The race condition itself probably doesn't matter, and users would
have been unlikely to run into it in practice. This problem has been
noted on-list when 680ee550d72 was discussed[1], but had not been
fixed.
This change is mainly intended to improve the readability of the code
involved, and to make reasoning about it more straightforward. It
wasn't as obvious what we were trying to do here, but by having an
"invoked_hook" it's clearer that e.g. our discard_cache() is happening
because of the earlier hook execution.
Let's also change this for the push-to-checkout hook. Now instead of
checking if the hook exists and either doing a push to checkout or a
push to deploy we'll always attempt a push to checkout. If the hook
doesn't exist we'll fall back on push to deploy. The same behavior as
before, without the TOCTOU race. See 0855331941b (receive-pack:
support push-to-checkout hook, 2014-12-01) for the introduction of the
previous behavior.
This leaves uses of hook_exists() in two places that matter. The
"reference-transaction" check in refs.c, see 67541597670 (refs:
implement reference transaction hook, 2020-06-19), and the
"prepare-commit-msg" hook, see 66618a50f9c (sequencer: run
'prepare-commit-msg' hook, 2018-01-24).
In both of those cases we're saving ourselves CPU time by not
preparing data for the hook that we'll then do nothing with if we
don't have the hook. So using this "invoked_hook" pattern doesn't make
sense in those cases.
The "reference-transaction" and "prepare-commit-msg" hook also aren't
racy. In those cases we'll skip the hook runs if we race with a new
hook being added, whereas in the TOCTOU races being fixed here we were
incorrectly skipping the required post-hook logic.
1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:33:46 +00:00
|
|
|
if (!no_verify && run_commit_hook(use_editor, index_file, &invoked_hook,
|
|
|
|
"pre-commit", NULL))
|
2008-02-05 10:01:46 +00:00
|
|
|
return 0;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2010-11-02 19:59:11 +00:00
|
|
|
if (squash_message) {
|
|
|
|
/*
|
|
|
|
* Insert the proper subject line before other commit
|
|
|
|
* message options add their content.
|
|
|
|
*/
|
|
|
|
if (use_message && !strcmp(use_message, squash_message))
|
|
|
|
strbuf_addstr(&sb, "squash! ");
|
|
|
|
else {
|
|
|
|
struct pretty_print_context ctx = {0};
|
|
|
|
struct commit *c;
|
|
|
|
c = lookup_commit_reference_by_name(squash_message);
|
|
|
|
if (!c)
|
2023-05-29 13:27:56 +00:00
|
|
|
die(_("could not lookup commit '%s'"), squash_message);
|
2010-11-02 19:59:11 +00:00
|
|
|
ctx.output_encoding = get_commit_output_encoding();
|
2023-03-28 13:58:51 +00:00
|
|
|
repo_format_commit_message(the_repository, c,
|
|
|
|
"squash! %s\n\n", &sb,
|
|
|
|
&ctx);
|
2010-11-02 19:59:11 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
commit: add support for --fixup <commit> -m"<extra message>"
Add support for supplying the -m option with --fixup. Doing so has
errored out ever since --fixup was introduced. Before this, the only
way to amend the fixup message while committing was to use --edit and
amend it in the editor.
The use-case for this feature is one of:
* Leaving a quick note to self when creating a --fixup commit when
it's not self-evident why the commit should be squashed without a
note into another one.
* (Ab)using the --fixup feature to "fix up" commits that have already
been pushed to a branch that doesn't allow non-fast-forwards,
i.e. just noting "this should have been part of that other commit",
and if the history ever got rewritten in the future the two should
be combined.
In such a case you might want to leave a small message,
e.g. "forgot this part, which broke XYZ".
With this, --fixup <commit> -m"More" -m"Details" will result in a
commit message like:
!fixup <subject of <commit>>
More
Details
The reason the test being added here seems to squash "More" at the end
of the subject line of the commit being fixed up is because the test
code is using "%s%b" so the body immediately follows the subject, it's
not a bug in this code, and other tests t7500-commit.sh do the same
thing.
When the --fixup option was initially added the "Option -m cannot be
combined" error was expanded from -c, -C and -F to also include
--fixup[1]
Those options could also support combining with -m, but given what
they do I can't think of a good use-case for doing that, so I have not
made the more invasive change of splitting up the logic in commit.c to
first act on those, and then on -m options.
1. d71b8ba7c9 ("commit: --fixup option for use with rebase
--autosquash", 2010-11-02)
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22 20:41:52 +00:00
|
|
|
if (have_option_m && !fixup_message) {
|
2007-11-11 17:36:39 +00:00
|
|
|
strbuf_addbuf(&sb, &message);
|
2008-02-05 07:04:18 +00:00
|
|
|
hook_arg1 = "message";
|
2007-11-08 16:59:00 +00:00
|
|
|
} else if (logfile && !strcmp(logfile, "-")) {
|
|
|
|
if (isatty(0))
|
2011-02-22 23:41:44 +00:00
|
|
|
fprintf(stderr, _("(reading log message from standard input)\n"));
|
2007-11-08 16:59:00 +00:00
|
|
|
if (strbuf_read(&sb, 0, 0) < 0)
|
2011-02-22 23:41:44 +00:00
|
|
|
die_errno(_("could not read log from standard input"));
|
2008-02-05 07:04:18 +00:00
|
|
|
hook_arg1 = "message";
|
2007-11-08 16:59:00 +00:00
|
|
|
} else if (logfile) {
|
|
|
|
if (strbuf_read_file(&sb, logfile, 0) < 0)
|
2011-02-22 23:41:44 +00:00
|
|
|
die_errno(_("could not read log file '%s'"),
|
2009-06-27 15:58:46 +00:00
|
|
|
logfile);
|
2008-02-05 07:04:18 +00:00
|
|
|
hook_arg1 = "message";
|
2007-11-08 16:59:00 +00:00
|
|
|
} else if (use_message) {
|
2014-01-30 15:15:56 +00:00
|
|
|
char *buffer;
|
2007-11-08 16:59:00 +00:00
|
|
|
buffer = strstr(use_message_buffer, "\n\n");
|
commit: do not complain of empty messages from -C
When we pick another commit's message, we die() immediately
if we find that it's empty and we are not going to run an
editor (i.e., when running "-C" instead of "-c"). However,
this check is redundant and harmful.
It's redundant because we will already notice the empty
message later, after we would have run the editor, and die
there (just as we would for a regular, not "-C" case, where
the user provided an empty message in the editor).
It's harmful for a few reasons:
1. It does not respect --allow-empty-message. As a result,
a "git rebase -i" cannot "pick" such a commit. So you
cannot even go back in time to fix it with a "reword"
or "edit" instruction.
2. It does not take into account other ways besides the
editor to modify the message. For example, "git commit
-C empty-commit -m foo" could take the author
information from empty-commit, but add a message to it.
There's more to do to make that work correctly (and
right now we explicitly forbid "-C with -m"), but this
removes one roadblock.
3. The existing check is not enough to prevent segfaults.
We try to find the "\n\n" header/body boundary in the
commit. If it is at the end of the string (i.e., no
body), _or_ if we cannot find it at all (i.e., a
truncated commit object), we consider the message
empty. With "-C", that's OK; we die in either case. But
with "-c", we continue on, and in the case of a
truncated commit may end up dereferencing NULL+2.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-25 23:11:15 +00:00
|
|
|
if (buffer)
|
2016-06-29 14:14:42 +00:00
|
|
|
strbuf_addstr(&sb, skip_blank_lines(buffer + 2));
|
2008-02-05 07:04:18 +00:00
|
|
|
hook_arg1 = "commit";
|
|
|
|
hook_arg2 = use_message;
|
2010-11-02 19:59:09 +00:00
|
|
|
} else if (fixup_message) {
|
|
|
|
struct pretty_print_context ctx = {0};
|
|
|
|
struct commit *commit;
|
2021-03-15 07:54:32 +00:00
|
|
|
char *fmt;
|
|
|
|
commit = lookup_commit_reference_by_name(fixup_commit);
|
2010-11-02 19:59:09 +00:00
|
|
|
if (!commit)
|
2023-05-29 13:27:56 +00:00
|
|
|
die(_("could not lookup commit '%s'"), fixup_commit);
|
2010-11-02 19:59:09 +00:00
|
|
|
ctx.output_encoding = get_commit_output_encoding();
|
2021-03-15 07:54:32 +00:00
|
|
|
fmt = xstrfmt("%s! %%s\n\n", fixup_prefix);
|
2023-03-28 13:58:51 +00:00
|
|
|
repo_format_commit_message(the_repository, commit, fmt, &sb,
|
|
|
|
&ctx);
|
2021-03-15 07:54:32 +00:00
|
|
|
free(fmt);
|
2010-11-02 19:59:09 +00:00
|
|
|
hook_arg1 = "message";
|
2021-03-15 07:54:32 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Only `-m` commit message option is checked here, as
|
|
|
|
* it supports `--fixup` to append the commit message.
|
|
|
|
*
|
|
|
|
* The other commit message options `-c`/`-C`/`-F` are
|
|
|
|
* incompatible with all the forms of `--fixup` and
|
|
|
|
* have already errored out while parsing the `git commit`
|
|
|
|
* options.
|
|
|
|
*/
|
|
|
|
if (have_option_m && !strcmp(fixup_prefix, "fixup"))
|
|
|
|
strbuf_addbuf(&sb, &message);
|
|
|
|
|
|
|
|
if (!strcmp(fixup_prefix, "amend")) {
|
|
|
|
if (have_option_m)
|
2022-01-05 20:02:24 +00:00
|
|
|
die(_("options '%s' and '%s:%s' cannot be used together"), "-m", "--fixup", fixup_message);
|
2021-03-15 07:54:32 +00:00
|
|
|
prepare_amend_commit(commit, &sb, &ctx);
|
|
|
|
}
|
2018-05-17 22:51:51 +00:00
|
|
|
} else if (!stat(git_path_merge_msg(the_repository), &statbuf)) {
|
2019-04-17 10:23:28 +00:00
|
|
|
size_t merge_msg_start;
|
|
|
|
|
2016-03-21 22:29:40 +00:00
|
|
|
/*
|
|
|
|
* prepend SQUASH_MSG here if it exists and a
|
|
|
|
* "merge --squash" was originally performed
|
|
|
|
*/
|
2018-05-17 22:51:51 +00:00
|
|
|
if (!stat(git_path_squash_msg(the_repository), &statbuf)) {
|
|
|
|
if (strbuf_read_file(&sb, git_path_squash_msg(the_repository), 0) < 0)
|
2016-03-21 22:29:40 +00:00
|
|
|
die_errno(_("could not read SQUASH_MSG"));
|
|
|
|
hook_arg1 = "squash";
|
|
|
|
} else
|
|
|
|
hook_arg1 = "merge";
|
2019-04-17 10:23:28 +00:00
|
|
|
|
|
|
|
merge_msg_start = sb.len;
|
2018-05-17 22:51:51 +00:00
|
|
|
if (strbuf_read_file(&sb, git_path_merge_msg(the_repository), 0) < 0)
|
2011-02-22 23:41:44 +00:00
|
|
|
die_errno(_("could not read MERGE_MSG"));
|
2019-04-17 10:23:28 +00:00
|
|
|
|
|
|
|
if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS &&
|
|
|
|
wt_status_locate_end(sb.buf + merge_msg_start,
|
|
|
|
sb.len - merge_msg_start) <
|
|
|
|
sb.len - merge_msg_start)
|
|
|
|
merge_contains_scissors = 1;
|
2018-05-17 22:51:51 +00:00
|
|
|
} else if (!stat(git_path_squash_msg(the_repository), &statbuf)) {
|
|
|
|
if (strbuf_read_file(&sb, git_path_squash_msg(the_repository), 0) < 0)
|
2011-02-22 23:41:44 +00:00
|
|
|
die_errno(_("could not read SQUASH_MSG"));
|
2008-02-05 07:04:18 +00:00
|
|
|
hook_arg1 = "squash";
|
2011-02-25 09:07:57 +00:00
|
|
|
} else if (template_file) {
|
2007-11-08 16:59:00 +00:00
|
|
|
if (strbuf_read_file(&sb, template_file, 0) < 0)
|
2011-02-22 23:41:44 +00:00
|
|
|
die_errno(_("could not read '%s'"), template_file);
|
2008-02-05 07:04:18 +00:00
|
|
|
hook_arg1 = "template";
|
2011-05-08 10:31:02 +00:00
|
|
|
clean_message_contents = 0;
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
|
|
|
|
2008-02-05 07:04:18 +00:00
|
|
|
/*
|
2011-02-20 04:12:29 +00:00
|
|
|
* The remaining cases don't modify the template message, but
|
|
|
|
* just set the argument(s) to the prepare-commit-msg hook.
|
2008-02-05 07:04:18 +00:00
|
|
|
*/
|
2011-02-20 04:12:29 +00:00
|
|
|
else if (whence == FROM_MERGE)
|
2008-02-05 07:04:18 +00:00
|
|
|
hook_arg1 = "merge";
|
2019-12-06 16:06:12 +00:00
|
|
|
else if (is_from_cherry_pick(whence) || whence == FROM_REBASE_PICK) {
|
2011-02-20 04:12:29 +00:00
|
|
|
hook_arg1 = "commit";
|
|
|
|
hook_arg2 = "CHERRY_PICK_HEAD";
|
|
|
|
}
|
2008-02-05 07:04:18 +00:00
|
|
|
|
2010-11-02 19:59:11 +00:00
|
|
|
if (squash_message) {
|
|
|
|
/*
|
|
|
|
* If squash_commit was used for the commit subject,
|
|
|
|
* then we're possibly hijacking other commit log options.
|
|
|
|
* Reset the hook args to tell the real story.
|
|
|
|
*/
|
|
|
|
hook_arg1 = "message";
|
|
|
|
hook_arg2 = "";
|
|
|
|
}
|
|
|
|
|
2016-05-24 19:19:50 +00:00
|
|
|
s->fp = fopen_for_writing(git_path_commit_editmsg());
|
2022-05-02 16:50:37 +00:00
|
|
|
if (!s->fp)
|
2016-05-24 19:19:50 +00:00
|
|
|
die_errno(_("could not open '%s'"), git_path_commit_editmsg());
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2013-09-06 17:43:07 +00:00
|
|
|
/* Ignore status.displayCommentPrefix: we do need comments in COMMIT_EDITMSG. */
|
|
|
|
old_display_comment_prefix = s->display_comment_prefix;
|
|
|
|
s->display_comment_prefix = 1;
|
|
|
|
|
2013-09-12 10:50:06 +00:00
|
|
|
/*
|
|
|
|
* Most hints are counter-productive when the commit has
|
|
|
|
* already started.
|
|
|
|
*/
|
|
|
|
s->hints = 0;
|
|
|
|
|
2011-05-08 10:31:02 +00:00
|
|
|
if (clean_message_contents)
|
2023-06-06 19:48:43 +00:00
|
|
|
strbuf_stripspace(&sb, '\0');
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2014-10-28 19:44:09 +00:00
|
|
|
if (signoff)
|
2016-11-02 17:29:17 +00:00
|
|
|
append_signoff(&sb, ignore_non_trailer(sb.buf, sb.len), 0);
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2011-02-26 05:10:49 +00:00
|
|
|
if (fwrite(sb.buf, 1, sb.len, s->fp) < sb.len)
|
2011-02-22 23:41:44 +00:00
|
|
|
die_errno(_("could not write commit template"));
|
2007-11-11 17:35:58 +00:00
|
|
|
|
2014-05-17 01:52:23 +00:00
|
|
|
if (auto_comment_line_char)
|
|
|
|
adjust_comment_line_char(&sb);
|
2007-11-08 16:59:00 +00:00
|
|
|
strbuf_release(&sb);
|
|
|
|
|
2008-05-04 16:04:51 +00:00
|
|
|
/* This checks if committer ident is explicitly given */
|
commit: check committer identity more strictly
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 060d4bb, 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: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-23 18:50:35 +00:00
|
|
|
strbuf_addstr(&committer_ident, git_committer_info(IDENT_STRICT));
|
2009-12-07 22:45:27 +00:00
|
|
|
if (use_editor && include_status) {
|
2014-01-30 15:15:56 +00:00
|
|
|
int ident_shown = 0;
|
|
|
|
int saved_color_setting;
|
2014-05-02 01:06:57 +00:00
|
|
|
struct ident_split ci, ai;
|
2021-07-09 18:07:32 +00:00
|
|
|
const char *hint_cleanup_all = allow_empty_message ?
|
|
|
|
_("Please enter the commit message for your changes."
|
|
|
|
" Lines starting\nwith '%c' will be ignored.\n") :
|
|
|
|
_("Please enter the commit message for your changes."
|
|
|
|
" Lines starting\nwith '%c' will be ignored, and an empty"
|
|
|
|
" message aborts the commit.\n");
|
|
|
|
const char *hint_cleanup_space = allow_empty_message ?
|
|
|
|
_("Please enter the commit message for your changes."
|
|
|
|
" Lines starting\n"
|
|
|
|
"with '%c' will be kept; you may remove them"
|
|
|
|
" yourself if you want to.\n") :
|
|
|
|
_("Please enter the commit message for your changes."
|
|
|
|
" Lines starting\n"
|
|
|
|
"with '%c' will be kept; you may remove them"
|
|
|
|
" yourself if you want to.\n"
|
|
|
|
"An empty message aborts the commit.\n");
|
2014-02-17 12:15:32 +00:00
|
|
|
if (whence != FROM_COMMIT) {
|
2019-04-17 10:23:28 +00:00
|
|
|
if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS &&
|
|
|
|
!merge_contains_scissors)
|
2014-02-17 12:15:32 +00:00
|
|
|
wt_status_add_cut_line(s->fp);
|
2020-08-21 16:59:36 +00:00
|
|
|
status_printf_ln(
|
|
|
|
s, GIT_COLOR_NORMAL,
|
2017-04-20 21:08:54 +00:00
|
|
|
whence == FROM_MERGE ?
|
2020-08-21 16:59:36 +00:00
|
|
|
_("\n"
|
|
|
|
"It looks like you may be committing a merge.\n"
|
|
|
|
"If this is not correct, please run\n"
|
|
|
|
" git update-ref -d MERGE_HEAD\n"
|
|
|
|
"and try again.\n") :
|
|
|
|
_("\n"
|
|
|
|
"It looks like you may be committing a cherry-pick.\n"
|
|
|
|
"If this is not correct, please run\n"
|
|
|
|
" git update-ref -d CHERRY_PICK_HEAD\n"
|
|
|
|
"and try again.\n"));
|
2014-02-17 12:15:32 +00:00
|
|
|
}
|
2008-02-05 10:01:46 +00:00
|
|
|
|
2011-02-26 05:11:37 +00:00
|
|
|
fprintf(s->fp, "\n");
|
2017-11-10 11:09:42 +00:00
|
|
|
if (cleanup_mode == COMMIT_MSG_CLEANUP_ALL)
|
2021-07-09 18:07:31 +00:00
|
|
|
status_printf(s, GIT_COLOR_NORMAL, hint_cleanup_all, comment_line_char);
|
2019-04-17 10:23:28 +00:00
|
|
|
else if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS) {
|
|
|
|
if (whence == FROM_COMMIT && !merge_contains_scissors)
|
|
|
|
wt_status_add_cut_line(s->fp);
|
|
|
|
} else /* COMMIT_MSG_CLEANUP_SPACE, that is. */
|
2021-07-09 18:07:31 +00:00
|
|
|
status_printf(s, GIT_COLOR_NORMAL, hint_cleanup_space, comment_line_char);
|
2008-02-05 10:01:46 +00:00
|
|
|
|
commit: loosen ident checks when generating template
When we generate the commit-message template, we try to
report an author or committer ident that will be of interest
to the user: an author that does not match the committer, or
a committer that was auto-configured.
When doing so, if we encounter what we consider to be a
bogus ident, we immediately die. This is a bad idea, because
our use of the idents here is purely informational. Any
ident rules should be enforced elsewhere, because commits
that do not invoke the editor will not even hit this code
path (e.g., "git commit -mfoo" would work, but "git commit"
would not). So at best, we are redundant with other checks,
and at worse, we actively prevent commits that should
otherwise be allowed.
We should therefore do the minimal parsing we can to get a
value and not do any validation (i.e., drop the call to
sane_ident_split()).
In theory we could notice when even our minimal parsing
fails to work, and do the sane thing for each check (e.g.,
if we have an author but can't parse the committer, assume
they are different and print the author). But we can
actually simplify this even further.
We know that the author and committer strings we are parsing
have been generated by us earlier in the program, and
therefore they must be parseable. We could just call
split_ident_line without even checking its return value,
knowing that it will put _something_ in the name/mail
fields. Of course, to protect ourselves against future
changes to the code, it makes sense to turn this into an
assert, so we are not surprised if our assumption fails.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-10 15:42:10 +00:00
|
|
|
/*
|
|
|
|
* These should never fail because they come from our own
|
|
|
|
* fmt_ident. They may fail the sane_ident test, but we know
|
|
|
|
* that the name and mail pointers will at least be valid,
|
|
|
|
* which is enough for our tests and printing here.
|
|
|
|
*/
|
|
|
|
assert_split_ident(&ai, author_ident);
|
|
|
|
assert_split_ident(&ci, &committer_ident);
|
2014-05-02 01:06:57 +00:00
|
|
|
|
|
|
|
if (ident_cmp(&ai, &ci))
|
2011-02-26 05:11:37 +00:00
|
|
|
status_printf_ln(s, GIT_COLOR_NORMAL,
|
2011-02-22 23:41:46 +00:00
|
|
|
_("%s"
|
2014-05-02 01:06:57 +00:00
|
|
|
"Author: %.*s <%.*s>"),
|
2011-02-26 05:11:37 +00:00
|
|
|
ident_shown++ ? "" : "\n",
|
2014-05-02 01:06:57 +00:00
|
|
|
(int)(ai.name_end - ai.name_begin), ai.name_begin,
|
|
|
|
(int)(ai.mail_end - ai.mail_begin), ai.mail_begin);
|
2008-05-04 16:04:50 +00:00
|
|
|
|
2014-05-02 01:10:01 +00:00
|
|
|
if (author_date_is_interesting())
|
|
|
|
status_printf_ln(s, GIT_COLOR_NORMAL,
|
|
|
|
_("%s"
|
|
|
|
"Date: %s"),
|
|
|
|
ident_shown++ ? "" : "\n",
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
show_ident_date(&ai, DATE_MODE(NORMAL)));
|
2008-05-04 16:04:50 +00:00
|
|
|
|
ident: keep separate "explicit" flags for author and committer
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: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-15 00:34:13 +00:00
|
|
|
if (!committer_ident_sufficiently_given())
|
2011-02-26 05:11:37 +00:00
|
|
|
status_printf_ln(s, GIT_COLOR_NORMAL,
|
2011-02-22 23:41:46 +00:00
|
|
|
_("%s"
|
2014-05-02 01:06:57 +00:00
|
|
|
"Committer: %.*s <%.*s>"),
|
2011-02-26 05:11:37 +00:00
|
|
|
ident_shown++ ? "" : "\n",
|
2014-05-02 01:06:57 +00:00
|
|
|
(int)(ci.name_end - ci.name_begin), ci.name_begin,
|
|
|
|
(int)(ci.mail_end - ci.mail_begin), ci.mail_begin);
|
2008-05-04 16:04:51 +00:00
|
|
|
|
2017-06-30 12:12:21 +00:00
|
|
|
status_printf_ln(s, GIT_COLOR_NORMAL, "%s", ""); /* Add new line for clarity */
|
2008-05-04 16:04:51 +00:00
|
|
|
|
2009-08-10 04:59:30 +00:00
|
|
|
saved_color_setting = s->use_color;
|
|
|
|
s->use_color = 0;
|
2018-09-06 00:53:27 +00:00
|
|
|
committable = run_status(s->fp, index_file, prefix, 1, s);
|
2009-08-10 04:59:30 +00:00
|
|
|
s->use_color = saved_color_setting;
|
commit: fix erroneous BUG, 'multiple renames on the same target? how?'
builtin/commit.c:prepare_to_commit() can call run_status() twice if
using the editor, including status, and the user attempts to record a
non-merge empty commit without explicit --allow-empty. If there is also
a rename involved as well (due to using 'git add -N'), then a BUG in
wt-status.c is triggered:
BUG: wt-status.c:476: multiple renames on the same target? how?
The reason we hit this bug is that both run_status() calls use the same
struct wt_status * (named s), and s->change is not freed between runs.
Changes are inserted into s with string_list_insert, which usually means
that the second run just recomputes all the same results and overwrites
what was computed the first time. However, ever since commit
176ea7479309 ("wt-status.c: handle worktree renames", 2017-12-27),
wt-status started checking for renames and copies but also added a
preventative check that d->rename_status wasn't already set and output a
BUG message if it was. The problem isn't that there are multiple rename
targets to a single path as the error implies, the problem is that 's'
is not freed/cleared between the two run_status() calls.
Ever since commit dc6b1d92ca9c ("wt-status: use settings from
git_diff_ui_config", 2018-05-04), which stopped hardcoding
DIFF_DETECT_RENAME and allowed users to ask for copy detection, this bug
has also been triggerable with a copy instead of a rename.
Fix the bug by clearing s->change. A better change might be to clean up
all of s between the two run_status() calls. A good first step towards
such a goal might be writing a function to free the necessary fields in
the wt_status * struct; a cursory glance at the code suggests all of its
allocated data is probably leaked. However, doing all that cleanup is a
bigger task for someone else interested to tackle; just fix the bug for
now.
Reported-by: Andrea Stacchiotti <andreastacchiotti@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27 17:36:57 +00:00
|
|
|
string_list_clear(&s->change, 1);
|
2008-02-05 10:01:46 +00:00
|
|
|
} else {
|
2017-02-20 00:10:14 +00:00
|
|
|
struct object_id oid;
|
2007-12-20 03:23:03 +00:00
|
|
|
const char *parent = "HEAD";
|
2007-11-28 21:13:08 +00:00
|
|
|
|
commit -a -m: allow the top-level tree to become empty again
In 03267e8656c (commit: discard partial cache before (re-)reading it,
2022-11-08), a memory leak was plugged by discarding any partial index
before re-reading it.
The problem with this memory leak fix is that it was based on an
incomplete understanding of the logic introduced in 7168624c353 (Do not
generate full commit log message if it is not going to be used,
2007-11-28).
That logic was introduced to add a shortcut when committing without
editing the commit message interactively. A part of that logic was to
ensure that the index was read into memory:
if (!active_nr && read_cache() < 0)
die(...)
Translation to English: If the index has not yet been read, read it, and
if that fails, error out.
That logic was incorrect, though: It used `!active_nr` as an indicator
that the index was not yet read. Usually this is not a problem because
in the vast majority of instances, the index contains at least one
entry.
And it was natural to do it this way because at the time that condition
was introduced, the `index_state` structure had no explicit flag to
indicate that it was initialized: This flag was only introduced in
913e0e99b6a (unpack_trees(): protect the handcrafted in-core index from
read_cache(), 2008-08-23), but that commit did not adjust the code path
where no index file was found and a new, pristine index was initialized.
Now, when the index does not contain any entry (which is quite
common in Git's test suite because it starts quite a many repositories
from scratch), subsequent calls to `do_read_index()` will mistake the
index not to be initialized, and read it again unnecessarily.
This is a problem because after initializing the empty index e.g. the
`cache_tree` in that index could have been initialized before a
subsequent call to `do_read_index()` wants to ensure an initialized
index. And if that subsequent call mistakes the index not to have been
initialized, it would lead to leaked memory.
The correct fix for that memory leak is to adjust the condition so that
it does not mistake `active_nr == 0` to mean that the index has not yet
been read.
Using the `initialized` flag instead, we avoid that mistake, and as a
bonus we can fix a bug at the same time that was introduced by the
memory leak fix: When deleting all tracked files and then asking `git
commit -a -m ...` to commit the result, Git would internally update the
index, then discard and re-read the index undoing the update, and fail
to commit anything.
This fixes https://github.com/git-for-windows/git/issues/4462
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 13:23:10 +00:00
|
|
|
if (!the_index.initialized && repo_read_index(the_repository) < 0)
|
|
|
|
die(_("Cannot read index"));
|
2007-11-28 21:13:08 +00:00
|
|
|
|
2007-12-20 03:23:03 +00:00
|
|
|
if (amend)
|
|
|
|
parent = "HEAD^1";
|
|
|
|
|
2023-03-28 13:58:46 +00:00
|
|
|
if (repo_get_oid(the_repository, parent, &oid)) {
|
2016-10-24 10:42:22 +00:00
|
|
|
int i, ita_nr = 0;
|
|
|
|
|
2021-04-01 01:49:45 +00:00
|
|
|
/* TODO: audit for interaction with sparse-index. */
|
|
|
|
ensure_full_index(&the_index);
|
2022-11-19 13:07:34 +00:00
|
|
|
for (i = 0; i < the_index.cache_nr; i++)
|
|
|
|
if (ce_intent_to_add(the_index.cache[i]))
|
2016-10-24 10:42:22 +00:00
|
|
|
ita_nr++;
|
2022-11-19 13:07:34 +00:00
|
|
|
committable = the_index.cache_nr - ita_nr > 0;
|
2016-10-24 10:42:22 +00:00
|
|
|
} else {
|
2014-04-05 16:59:36 +00:00
|
|
|
/*
|
|
|
|
* Unless the user did explicitly request a submodule
|
|
|
|
* ignore mode by passing a command line option we do
|
|
|
|
* not ignore any changed submodule SHA-1s when
|
|
|
|
* comparing index and parent, no matter what is
|
|
|
|
* configured. Otherwise we won't commit any
|
|
|
|
* submodules which were manually staged, which would
|
|
|
|
* be really confusing.
|
|
|
|
*/
|
2017-10-31 18:19:05 +00:00
|
|
|
struct diff_flags flags = DIFF_FLAGS_INIT;
|
2017-10-31 18:19:11 +00:00
|
|
|
flags.override_submodule_config = 1;
|
2014-04-05 16:59:36 +00:00
|
|
|
if (ignore_submodule_arg &&
|
|
|
|
!strcmp(ignore_submodule_arg, "all"))
|
2017-10-31 18:19:11 +00:00
|
|
|
flags.ignore_submodules = 1;
|
2018-11-10 05:49:04 +00:00
|
|
|
committable = index_differs_from(the_repository,
|
|
|
|
parent, &flags, 1);
|
2014-04-05 16:59:36 +00:00
|
|
|
}
|
2008-02-05 10:01:46 +00:00
|
|
|
}
|
2010-12-21 01:00:36 +00:00
|
|
|
strbuf_release(&committer_ident);
|
2007-12-23 03:22:29 +00:00
|
|
|
|
2011-02-26 05:10:49 +00:00
|
|
|
fclose(s->fp);
|
2007-11-28 21:13:08 +00:00
|
|
|
|
2021-03-23 13:55:57 +00:00
|
|
|
if (trailer_args.nr) {
|
|
|
|
struct child_process run_trailer = CHILD_PROCESS_INIT;
|
|
|
|
|
|
|
|
strvec_pushl(&run_trailer.args, "interpret-trailers",
|
commit: pass --no-divider to interpret-trailers
When git-commit sees any "--trailer" options, it passes the
COMMIT_EDITMSG file through git-interpret-trailers. But it does so
without passing --no-divider, which means that interpret-trailers will
look for a "---" divider to signal the end of the commit message.
That behavior doesn't make any sense in this context; we know we have a
complete and solitary commit message, not something we have to further
parse. And as a result, we'll do the wrong thing if the commit message
contains a "---" marker (which otherwise is not syntactically
significant), inserting any new trailers at the wrong spot.
We can fix this by passing --no-divider. This is the exact situation for
which it was added in 1688c9a489 (interpret-trailers: allow suppressing
"---" divider, 2018-08-22). As noted in the message for that commit, it
just adds the mechanism, and further patches were needed to trigger it
from various callers. We did that back then in a few spots, like
ffce7f590f (sequencer: ignore "---" divider when parsing trailers,
2018-08-22), but obviously missed this one.
Reported-by: <eric.frederich@siemens.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-17 04:26:24 +00:00
|
|
|
"--in-place", "--no-divider",
|
|
|
|
git_path_commit_editmsg(), NULL);
|
2021-03-23 13:55:57 +00:00
|
|
|
strvec_pushv(&run_trailer.args, trailer_args.v);
|
|
|
|
run_trailer.git_cmd = 1;
|
|
|
|
if (run_command(&run_trailer))
|
|
|
|
die(_("unable to pass trailers to --trailers"));
|
|
|
|
strvec_clear(&trailer_args);
|
|
|
|
}
|
|
|
|
|
2011-02-20 04:12:29 +00:00
|
|
|
/*
|
|
|
|
* Reject an attempt to record a non-merge empty commit without
|
|
|
|
* explicit --allow-empty. In the cherry-pick case, it may be
|
|
|
|
* empty due to conflict resolution, which the user should okay.
|
|
|
|
*/
|
2018-09-06 00:53:27 +00:00
|
|
|
if (!committable && whence != FROM_MERGE && !allow_empty &&
|
2011-08-19 18:58:18 +00:00
|
|
|
!(amend && is_a_merge(current_head))) {
|
2021-08-23 10:44:00 +00:00
|
|
|
s->hints = advice_enabled(ADVICE_STATUS_HINTS);
|
2013-09-06 17:43:07 +00:00
|
|
|
s->display_comment_prefix = old_display_comment_prefix;
|
2009-08-10 04:59:30 +00:00
|
|
|
run_status(stdout, index_file, prefix, 0, s);
|
2010-06-07 00:41:46 +00:00
|
|
|
if (amend)
|
2011-02-22 23:41:49 +00:00
|
|
|
fputs(_(empty_amend_advice), stderr);
|
2019-12-06 16:06:12 +00:00
|
|
|
else if (is_from_cherry_pick(whence) ||
|
|
|
|
whence == FROM_REBASE_PICK) {
|
2011-04-02 00:55:55 +00:00
|
|
|
fputs(_(empty_cherry_pick_advice), stderr);
|
2019-12-06 16:06:10 +00:00
|
|
|
if (whence == FROM_CHERRY_PICK_SINGLE)
|
commit: tweak empty cherry pick advice for sequencer
When we refuse to make an empty commit, we check whether we
are in a cherry-pick in order to give better advice on how
to proceed. We instruct the user to repeat the commit with
"--allow-empty" to force the commit, or to use "git reset"
to skip it and abort the cherry-pick.
In the case of a single cherry-pick, the distinction between
skipping and aborting is not important, as there is no more
work to be done afterwards. When we are using the sequencer
to cherry pick a series of commits, though, the instruction
is confusing: does it skip this commit, or does it abort the
rest of the cherry-pick?
It does skip, after which the user can continue the
cherry-pick. This is the right thing to be advising the user
to do, but let's make it more clear what will happen, both
by using the word "skip", and by mentioning that the rest of
the sequence can be continued via "cherry-pick --continue"
(whether we skip or take the commit).
Noticed-by: Ramkumar Ramachandra <artagnon@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-26 23:39:28 +00:00
|
|
|
fputs(_(empty_cherry_pick_advice_single), stderr);
|
2019-12-06 16:06:12 +00:00
|
|
|
else if (whence == FROM_CHERRY_PICK_MULTI)
|
commit: tweak empty cherry pick advice for sequencer
When we refuse to make an empty commit, we check whether we
are in a cherry-pick in order to give better advice on how
to proceed. We instruct the user to repeat the commit with
"--allow-empty" to force the commit, or to use "git reset"
to skip it and abort the cherry-pick.
In the case of a single cherry-pick, the distinction between
skipping and aborting is not important, as there is no more
work to be done afterwards. When we are using the sequencer
to cherry pick a series of commits, though, the instruction
is confusing: does it skip this commit, or does it abort the
rest of the cherry-pick?
It does skip, after which the user can continue the
cherry-pick. This is the right thing to be advising the user
to do, but let's make it more clear what will happen, both
by using the word "skip", and by mentioning that the rest of
the sequence can be continued via "cherry-pick --continue"
(whether we skip or take the commit).
Noticed-by: Ramkumar Ramachandra <artagnon@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-26 23:39:28 +00:00
|
|
|
fputs(_(empty_cherry_pick_advice_multi), stderr);
|
2019-12-06 16:06:12 +00:00
|
|
|
else
|
|
|
|
fputs(_(empty_rebase_pick_advice), stderr);
|
commit: tweak empty cherry pick advice for sequencer
When we refuse to make an empty commit, we check whether we
are in a cherry-pick in order to give better advice on how
to proceed. We instruct the user to repeat the commit with
"--allow-empty" to force the commit, or to use "git reset"
to skip it and abort the cherry-pick.
In the case of a single cherry-pick, the distinction between
skipping and aborting is not important, as there is no more
work to be done afterwards. When we are using the sequencer
to cherry pick a series of commits, though, the instruction
is confusing: does it skip this commit, or does it abort the
rest of the cherry-pick?
It does skip, after which the user can continue the
cherry-pick. This is the right thing to be advising the user
to do, but let's make it more clear what will happen, both
by using the word "skip", and by mentioning that the rest of
the sequence can be continued via "cherry-pick --continue"
(whether we skip or take the commit).
Noticed-by: Ramkumar Ramachandra <artagnon@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-26 23:39:28 +00:00
|
|
|
}
|
2008-02-05 10:01:46 +00:00
|
|
|
return 0;
|
2007-11-28 21:13:08 +00:00
|
|
|
}
|
|
|
|
|
hooks: fix an obscure TOCTOU "did we just run a hook?" race
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in
680ee550d72 (commit: skip discarding the index if there is no
pre-commit hook, 2017-08-14).
This obscure race condition can occur if we e.g. ran the "pre-commit"
hook and it modified the index, but hook_exists() returns false later
on (e.g., because the hook itself went away, the directory became
unreadable, etc.). Then we won't call discard_cache() when we should
have.
The race condition itself probably doesn't matter, and users would
have been unlikely to run into it in practice. This problem has been
noted on-list when 680ee550d72 was discussed[1], but had not been
fixed.
This change is mainly intended to improve the readability of the code
involved, and to make reasoning about it more straightforward. It
wasn't as obvious what we were trying to do here, but by having an
"invoked_hook" it's clearer that e.g. our discard_cache() is happening
because of the earlier hook execution.
Let's also change this for the push-to-checkout hook. Now instead of
checking if the hook exists and either doing a push to checkout or a
push to deploy we'll always attempt a push to checkout. If the hook
doesn't exist we'll fall back on push to deploy. The same behavior as
before, without the TOCTOU race. See 0855331941b (receive-pack:
support push-to-checkout hook, 2014-12-01) for the introduction of the
previous behavior.
This leaves uses of hook_exists() in two places that matter. The
"reference-transaction" check in refs.c, see 67541597670 (refs:
implement reference transaction hook, 2020-06-19), and the
"prepare-commit-msg" hook, see 66618a50f9c (sequencer: run
'prepare-commit-msg' hook, 2018-01-24).
In both of those cases we're saving ourselves CPU time by not
preparing data for the hook that we'll then do nothing with if we
don't have the hook. So using this "invoked_hook" pattern doesn't make
sense in those cases.
The "reference-transaction" and "prepare-commit-msg" hook also aren't
racy. In those cases we'll skip the hook runs if we race with a new
hook being added, whereas in the TOCTOU races being fixed here we were
incorrectly skipping the required post-hook logic.
1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:33:46 +00:00
|
|
|
if (!no_verify && invoked_hook) {
|
2017-08-14 21:54:25 +00:00
|
|
|
/*
|
hooks: fix an obscure TOCTOU "did we just run a hook?" race
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in
680ee550d72 (commit: skip discarding the index if there is no
pre-commit hook, 2017-08-14).
This obscure race condition can occur if we e.g. ran the "pre-commit"
hook and it modified the index, but hook_exists() returns false later
on (e.g., because the hook itself went away, the directory became
unreadable, etc.). Then we won't call discard_cache() when we should
have.
The race condition itself probably doesn't matter, and users would
have been unlikely to run into it in practice. This problem has been
noted on-list when 680ee550d72 was discussed[1], but had not been
fixed.
This change is mainly intended to improve the readability of the code
involved, and to make reasoning about it more straightforward. It
wasn't as obvious what we were trying to do here, but by having an
"invoked_hook" it's clearer that e.g. our discard_cache() is happening
because of the earlier hook execution.
Let's also change this for the push-to-checkout hook. Now instead of
checking if the hook exists and either doing a push to checkout or a
push to deploy we'll always attempt a push to checkout. If the hook
doesn't exist we'll fall back on push to deploy. The same behavior as
before, without the TOCTOU race. See 0855331941b (receive-pack:
support push-to-checkout hook, 2014-12-01) for the introduction of the
previous behavior.
This leaves uses of hook_exists() in two places that matter. The
"reference-transaction" check in refs.c, see 67541597670 (refs:
implement reference transaction hook, 2020-06-19), and the
"prepare-commit-msg" hook, see 66618a50f9c (sequencer: run
'prepare-commit-msg' hook, 2018-01-24).
In both of those cases we're saving ourselves CPU time by not
preparing data for the hook that we'll then do nothing with if we
don't have the hook. So using this "invoked_hook" pattern doesn't make
sense in those cases.
The "reference-transaction" and "prepare-commit-msg" hook also aren't
racy. In those cases we'll skip the hook runs if we race with a new
hook being added, whereas in the TOCTOU races being fixed here we were
incorrectly skipping the required post-hook logic.
1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:33:46 +00:00
|
|
|
* Re-read the index as the pre-commit-commit hook was invoked
|
|
|
|
* and could have updated it. We must do this before we invoke
|
2017-08-14 21:54:25 +00:00
|
|
|
* the editor and after we invoke run_status above.
|
|
|
|
*/
|
2022-11-19 13:07:38 +00:00
|
|
|
discard_index(&the_index);
|
2017-08-14 21:54:25 +00:00
|
|
|
}
|
2022-11-19 13:07:38 +00:00
|
|
|
read_index_from(&the_index, index_file, get_git_dir());
|
2017-08-14 21:54:25 +00:00
|
|
|
|
2023-02-10 10:28:38 +00:00
|
|
|
if (cache_tree_update(&the_index, 0)) {
|
2011-02-22 23:41:44 +00:00
|
|
|
error(_("Error building trees"));
|
2008-02-05 10:01:46 +00:00
|
|
|
return 0;
|
2007-11-28 21:13:08 +00:00
|
|
|
}
|
2007-11-08 16:59:00 +00:00
|
|
|
|
hooks: fix an obscure TOCTOU "did we just run a hook?" race
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in
680ee550d72 (commit: skip discarding the index if there is no
pre-commit hook, 2017-08-14).
This obscure race condition can occur if we e.g. ran the "pre-commit"
hook and it modified the index, but hook_exists() returns false later
on (e.g., because the hook itself went away, the directory became
unreadable, etc.). Then we won't call discard_cache() when we should
have.
The race condition itself probably doesn't matter, and users would
have been unlikely to run into it in practice. This problem has been
noted on-list when 680ee550d72 was discussed[1], but had not been
fixed.
This change is mainly intended to improve the readability of the code
involved, and to make reasoning about it more straightforward. It
wasn't as obvious what we were trying to do here, but by having an
"invoked_hook" it's clearer that e.g. our discard_cache() is happening
because of the earlier hook execution.
Let's also change this for the push-to-checkout hook. Now instead of
checking if the hook exists and either doing a push to checkout or a
push to deploy we'll always attempt a push to checkout. If the hook
doesn't exist we'll fall back on push to deploy. The same behavior as
before, without the TOCTOU race. See 0855331941b (receive-pack:
support push-to-checkout hook, 2014-12-01) for the introduction of the
previous behavior.
This leaves uses of hook_exists() in two places that matter. The
"reference-transaction" check in refs.c, see 67541597670 (refs:
implement reference transaction hook, 2020-06-19), and the
"prepare-commit-msg" hook, see 66618a50f9c (sequencer: run
'prepare-commit-msg' hook, 2018-01-24).
In both of those cases we're saving ourselves CPU time by not
preparing data for the hook that we'll then do nothing with if we
don't have the hook. So using this "invoked_hook" pattern doesn't make
sense in those cases.
The "reference-transaction" and "prepare-commit-msg" hook also aren't
racy. In those cases we'll skip the hook runs if we race with a new
hook being added, whereas in the TOCTOU races being fixed here we were
incorrectly skipping the required post-hook logic.
1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:33:46 +00:00
|
|
|
if (run_commit_hook(use_editor, index_file, NULL, "prepare-commit-msg",
|
2016-05-24 19:19:50 +00:00
|
|
|
git_path_commit_editmsg(), hook_arg1, hook_arg2, NULL))
|
2008-02-05 07:04:18 +00:00
|
|
|
return 0;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2008-02-05 10:01:46 +00:00
|
|
|
if (use_editor) {
|
2020-07-28 20:24:27 +00:00
|
|
|
struct strvec env = STRVEC_INIT;
|
2017-01-13 17:58:00 +00:00
|
|
|
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_pushf(&env, "GIT_INDEX_FILE=%s", index_file);
|
2020-07-29 00:37:20 +00:00
|
|
|
if (launch_editor(git_path_commit_editmsg(), NULL, env.v)) {
|
2008-07-25 16:28:42 +00:00
|
|
|
fprintf(stderr,
|
2011-02-22 23:41:44 +00:00
|
|
|
_("Please supply the message using either -m or -F option.\n"));
|
2008-07-25 16:28:42 +00:00
|
|
|
exit(1);
|
|
|
|
}
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_clear(&env);
|
2008-02-05 10:01:46 +00:00
|
|
|
}
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2008-02-05 10:01:46 +00:00
|
|
|
if (!no_verify &&
|
hooks: fix an obscure TOCTOU "did we just run a hook?" race
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in
680ee550d72 (commit: skip discarding the index if there is no
pre-commit hook, 2017-08-14).
This obscure race condition can occur if we e.g. ran the "pre-commit"
hook and it modified the index, but hook_exists() returns false later
on (e.g., because the hook itself went away, the directory became
unreadable, etc.). Then we won't call discard_cache() when we should
have.
The race condition itself probably doesn't matter, and users would
have been unlikely to run into it in practice. This problem has been
noted on-list when 680ee550d72 was discussed[1], but had not been
fixed.
This change is mainly intended to improve the readability of the code
involved, and to make reasoning about it more straightforward. It
wasn't as obvious what we were trying to do here, but by having an
"invoked_hook" it's clearer that e.g. our discard_cache() is happening
because of the earlier hook execution.
Let's also change this for the push-to-checkout hook. Now instead of
checking if the hook exists and either doing a push to checkout or a
push to deploy we'll always attempt a push to checkout. If the hook
doesn't exist we'll fall back on push to deploy. The same behavior as
before, without the TOCTOU race. See 0855331941b (receive-pack:
support push-to-checkout hook, 2014-12-01) for the introduction of the
previous behavior.
This leaves uses of hook_exists() in two places that matter. The
"reference-transaction" check in refs.c, see 67541597670 (refs:
implement reference transaction hook, 2020-06-19), and the
"prepare-commit-msg" hook, see 66618a50f9c (sequencer: run
'prepare-commit-msg' hook, 2018-01-24).
In both of those cases we're saving ourselves CPU time by not
preparing data for the hook that we'll then do nothing with if we
don't have the hook. So using this "invoked_hook" pattern doesn't make
sense in those cases.
The "reference-transaction" and "prepare-commit-msg" hook also aren't
racy. In those cases we'll skip the hook runs if we race with a new
hook being added, whereas in the TOCTOU races being fixed here we were
incorrectly skipping the required post-hook logic.
1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:33:46 +00:00
|
|
|
run_commit_hook(use_editor, index_file, NULL, "commit-msg",
|
|
|
|
git_path_commit_editmsg(), NULL)) {
|
2008-02-05 10:01:46 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2008-02-05 10:01:46 +00:00
|
|
|
return 1;
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
|
|
|
|
2008-08-27 06:13:13 +00:00
|
|
|
static const char *find_author_by_nickname(const char *name)
|
|
|
|
{
|
|
|
|
struct rev_info revs;
|
|
|
|
struct commit *commit;
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
const char *av[20];
|
|
|
|
int ac = 0;
|
|
|
|
|
2018-09-21 15:57:38 +00:00
|
|
|
repo_init_revisions(the_repository, &revs, NULL);
|
2008-08-27 06:13:13 +00:00
|
|
|
strbuf_addf(&buf, "--author=%s", name);
|
|
|
|
av[++ac] = "--all";
|
|
|
|
av[++ac] = "-i";
|
|
|
|
av[++ac] = buf.buf;
|
|
|
|
av[++ac] = NULL;
|
|
|
|
setup_revisions(ac, av, &revs, NULL);
|
revisions API: have release_revisions() release "mailmap"
Extend the the release_revisions() function so that it frees the
"mailmap" in the "struct rev_info".
The log family of functions now calls the clear_mailmap() function
added in fa8afd18e5a (revisions API: provide and use a
release_revisions(), 2021-09-19), allowing us to whitelist some tests
with "TEST_PASSES_SANITIZE_LEAK=true".
Unfortunately having a pointer to a mailmap in "struct rev_info"
instead of an embedded member that we "own" get a bit messy, as can be
seen in the change to builtin/commit.c.
When we free() this data we won't be able to tell apart a pointer to a
"mailmap" on the heap from one on the stack. As seen in
ea57bc0d41b (log: add --use-mailmap option, 2013-01-05) the "log"
family allocates it on the heap, but in the find_author_by_nickname()
code added in ea16794e430 (commit: search author pattern against
mailmap, 2013-08-23) we allocated it on the stack instead.
Ideally we'd simply change that member to a "struct string_list
mailmap" and never free() the "mailmap" itself, but that would be a
much larger change to the revisions API.
We have code that needs to hand an existing "mailmap" to a "struct
rev_info", while we could change all of that, let's not go there
now.
The complexity isn't in the ownership of the "mailmap" per-se, but
that various things assume a "rev_info.mailmap == NULL" means "doesn't
want mailmap", if we changed that to an init'd "struct string_list
we'd need to carefully refactor things to change those assumptions.
Let's instead always free() it, and simply declare that if you add
such a "mailmap" it must be allocated on the heap. Any modern libc
will correctly panic if we free() a stack variable, so this should be
safe going forward.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13 20:01:46 +00:00
|
|
|
revs.mailmap = xmalloc(sizeof(struct string_list));
|
|
|
|
string_list_init_nodup(revs.mailmap);
|
2021-01-12 20:18:06 +00:00
|
|
|
read_mailmap(revs.mailmap);
|
2013-08-23 13:48:31 +00:00
|
|
|
|
2014-08-10 21:33:26 +00:00
|
|
|
if (prepare_revision_walk(&revs))
|
|
|
|
die(_("revision walk setup failed"));
|
2008-08-27 06:13:13 +00:00
|
|
|
commit = get_revision(&revs);
|
|
|
|
if (commit) {
|
2009-10-19 15:48:08 +00:00
|
|
|
struct pretty_print_context ctx = {0};
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
ctx.date_mode.type = DATE_NORMAL;
|
2008-08-27 06:13:13 +00:00
|
|
|
strbuf_release(&buf);
|
2023-03-28 13:58:51 +00:00
|
|
|
repo_format_commit_message(the_repository, commit,
|
|
|
|
"%aN <%aE>", &buf, &ctx);
|
2022-04-13 20:01:36 +00:00
|
|
|
release_revisions(&revs);
|
2008-08-27 06:13:13 +00:00
|
|
|
return strbuf_detach(&buf, NULL);
|
|
|
|
}
|
2015-01-26 15:48:33 +00:00
|
|
|
die(_("--author '%s' is not 'Name <email>' and matches no existing author"), name);
|
2008-08-27 06:13:13 +00:00
|
|
|
}
|
|
|
|
|
status: add option to show ignored files differently
Teach the status command more flexibility in how ignored files are
reported. Currently, the reporting of ignored files and untracked
files are linked. You cannot control how ignored files are reported
independently of how untracked files are reported (i.e. `all` vs
`normal`). This makes it impossible to show untracked files with the
`all` option, but show ignored files with the `normal` option.
This work 1) adds the ability to control the reporting of ignored
files independently of untracked files and 2) introduces the concept
of status reporting ignored paths that explicitly match an ignored
pattern. There are 2 benefits to these changes: 1) if a consumer needs
all untracked files but not all ignored files, there is a performance
benefit to not scanning all contents of an ignored directory and 2)
returning ignored files that explicitly match a path allow a consumer
to make more informed decisions about when a status result might be
stale.
This commit implements --ignored=matching with --untracked-files=all.
The following commit will implement --ignored=matching with
--untracked=files=normal.
As an example of where this flexibility could be useful is that our
application (Visual Studio) runs the status command and presents the
output. It shows all untracked files individually (e.g. using the
'--untracked-files==all' option), and would like to know about which
paths are ignored. It uses information about ignored paths to make
decisions about when the status result might have changed.
Additionally, many projects place build output into directories inside
a repository's working directory (e.g. in "bin/" and "obj/"
directories). Normal usage is to explicitly ignore these 2 directory
names in the .gitignore file (rather than or in addition to the *.obj
pattern).If an application could know that these directories are
explicitly ignored, it could infer that all contents are ignored as
well and make better informed decisions about files in these
directories. It could infer that any changes under these paths would
not affect the output of status. Additionally, there can be a
significant performance benefit by avoiding scanning through ignored
directories.
When status is set to report matching ignored files, it has the
following behavior. Ignored files and directories that explicitly
match an exclude pattern are reported. If an ignored directory matches
an exclude pattern, then the path of the directory is returned. If a
directory does not match an exclude pattern, but all of its contents
are ignored, then the contained files are reported instead of the
directory.
Signed-off-by: Jameson Miller <jamill@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-30 17:21:37 +00:00
|
|
|
static void handle_ignored_arg(struct wt_status *s)
|
|
|
|
{
|
|
|
|
if (!ignored_arg)
|
|
|
|
; /* default already initialized */
|
|
|
|
else if (!strcmp(ignored_arg, "traditional"))
|
|
|
|
s->show_ignored_mode = SHOW_TRADITIONAL_IGNORED;
|
|
|
|
else if (!strcmp(ignored_arg, "no"))
|
|
|
|
s->show_ignored_mode = SHOW_NO_IGNORED;
|
|
|
|
else if (!strcmp(ignored_arg, "matching"))
|
|
|
|
s->show_ignored_mode = SHOW_MATCHING_IGNORED;
|
|
|
|
else
|
|
|
|
die(_("Invalid ignored mode '%s'"), ignored_arg);
|
|
|
|
}
|
2009-08-08 06:31:57 +00:00
|
|
|
|
|
|
|
static void handle_untracked_files_arg(struct wt_status *s)
|
|
|
|
{
|
|
|
|
if (!untracked_files_arg)
|
|
|
|
; /* default already initialized */
|
|
|
|
else if (!strcmp(untracked_files_arg, "no"))
|
|
|
|
s->show_untracked_files = SHOW_NO_UNTRACKED_FILES;
|
|
|
|
else if (!strcmp(untracked_files_arg, "normal"))
|
|
|
|
s->show_untracked_files = SHOW_NORMAL_UNTRACKED_FILES;
|
|
|
|
else if (!strcmp(untracked_files_arg, "all"))
|
|
|
|
s->show_untracked_files = SHOW_ALL_UNTRACKED_FILES;
|
2019-02-16 11:24:41 +00:00
|
|
|
/*
|
|
|
|
* Please update $__git_untracked_file_modes in
|
|
|
|
* git-completion.bash when you add new options
|
|
|
|
*/
|
2009-08-08 06:31:57 +00:00
|
|
|
else
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("Invalid untracked files mode '%s'"), untracked_files_arg);
|
2009-08-08 06:31:57 +00:00
|
|
|
}
|
|
|
|
|
2011-02-20 04:12:29 +00:00
|
|
|
static const char *read_commit_message(const char *name)
|
|
|
|
{
|
2013-01-26 09:44:06 +00:00
|
|
|
const char *out_enc;
|
2011-02-20 04:12:29 +00:00
|
|
|
struct commit *commit;
|
|
|
|
|
|
|
|
commit = lookup_commit_reference_by_name(name);
|
|
|
|
if (!commit)
|
2023-05-29 13:27:56 +00:00
|
|
|
die(_("could not lookup commit '%s'"), name);
|
2011-02-20 04:12:29 +00:00
|
|
|
out_enc = get_commit_output_encoding();
|
2023-03-28 13:58:48 +00:00
|
|
|
return repo_logmsg_reencode(the_repository, commit, NULL, out_enc);
|
2011-02-20 04:12:29 +00:00
|
|
|
}
|
|
|
|
|
2013-06-24 18:41:40 +00:00
|
|
|
/*
|
|
|
|
* Enumerate what needs to be propagated when --porcelain
|
|
|
|
* is not in effect here.
|
|
|
|
*/
|
|
|
|
static struct status_deferred_config {
|
2016-08-05 22:00:27 +00:00
|
|
|
enum wt_status_format status_format;
|
2013-06-24 18:41:40 +00:00
|
|
|
int show_branch;
|
2019-06-18 20:21:25 +00:00
|
|
|
enum ahead_behind_flags ahead_behind;
|
2013-06-24 18:41:40 +00:00
|
|
|
} status_deferred_config = {
|
|
|
|
STATUS_FORMAT_UNSPECIFIED,
|
2019-06-18 20:21:25 +00:00
|
|
|
-1, /* unspecified */
|
|
|
|
AHEAD_BEHIND_UNSPECIFIED,
|
2013-06-24 18:41:40 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static void finalize_deferred_config(struct wt_status *s)
|
|
|
|
{
|
|
|
|
int use_deferred_config = (status_format != STATUS_FORMAT_PORCELAIN &&
|
2016-08-11 14:45:57 +00:00
|
|
|
status_format != STATUS_FORMAT_PORCELAIN_V2 &&
|
2013-06-24 18:41:40 +00:00
|
|
|
!s->null_termination);
|
|
|
|
|
|
|
|
if (s->null_termination) {
|
|
|
|
if (status_format == STATUS_FORMAT_NONE ||
|
|
|
|
status_format == STATUS_FORMAT_UNSPECIFIED)
|
|
|
|
status_format = STATUS_FORMAT_PORCELAIN;
|
|
|
|
else if (status_format == STATUS_FORMAT_LONG)
|
2022-01-05 20:02:16 +00:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--long", "-z");
|
2013-06-24 18:41:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (use_deferred_config && status_format == STATUS_FORMAT_UNSPECIFIED)
|
|
|
|
status_format = status_deferred_config.status_format;
|
|
|
|
if (status_format == STATUS_FORMAT_UNSPECIFIED)
|
|
|
|
status_format = STATUS_FORMAT_NONE;
|
|
|
|
|
|
|
|
if (use_deferred_config && s->show_branch < 0)
|
|
|
|
s->show_branch = status_deferred_config.show_branch;
|
|
|
|
if (s->show_branch < 0)
|
|
|
|
s->show_branch = 0;
|
2018-01-09 18:50:16 +00:00
|
|
|
|
2019-06-18 20:21:25 +00:00
|
|
|
/*
|
|
|
|
* If the user did not give a "--[no]-ahead-behind" command
|
2019-06-18 20:21:28 +00:00
|
|
|
* line argument *AND* we will print in a human-readable format
|
|
|
|
* (short, long etc.) then we inherit from the status.aheadbehind
|
|
|
|
* config setting. In all other cases (and porcelain V[12] formats
|
|
|
|
* in particular), we inherit _FULL for backwards compatibility.
|
2019-06-18 20:21:25 +00:00
|
|
|
*/
|
2019-06-18 20:21:28 +00:00
|
|
|
if (use_deferred_config &&
|
|
|
|
s->ahead_behind_flags == AHEAD_BEHIND_UNSPECIFIED)
|
2019-06-18 20:21:25 +00:00
|
|
|
s->ahead_behind_flags = status_deferred_config.ahead_behind;
|
|
|
|
|
2018-01-09 18:50:16 +00:00
|
|
|
if (s->ahead_behind_flags == AHEAD_BEHIND_UNSPECIFIED)
|
|
|
|
s->ahead_behind_flags = AHEAD_BEHIND_FULL;
|
2013-06-24 18:41:40 +00:00
|
|
|
}
|
|
|
|
|
2021-03-15 07:54:33 +00:00
|
|
|
static void check_fixup_reword_options(int argc, const char *argv[]) {
|
|
|
|
if (whence != FROM_COMMIT) {
|
|
|
|
if (whence == FROM_MERGE)
|
|
|
|
die(_("You are in the middle of a merge -- cannot reword."));
|
|
|
|
else if (is_from_cherry_pick(whence))
|
|
|
|
die(_("You are in the middle of a cherry-pick -- cannot reword."));
|
|
|
|
}
|
|
|
|
if (argc)
|
2022-01-05 20:02:24 +00:00
|
|
|
die(_("reword option of '%s' and path '%s' cannot be used together"), "--fixup", *argv);
|
2021-03-15 07:54:33 +00:00
|
|
|
if (patch_interactive || interactive || all || also || only)
|
2022-01-05 20:02:24 +00:00
|
|
|
die(_("reword option of '%s' and '%s' cannot be used together"),
|
|
|
|
"--fixup", "--patch/--interactive/--all/--include/--only");
|
2021-03-15 07:54:33 +00:00
|
|
|
}
|
|
|
|
|
2007-12-03 05:02:09 +00:00
|
|
|
static int parse_and_validate_options(int argc, const char *argv[],
|
2012-05-07 19:18:26 +00:00
|
|
|
const struct option *options,
|
2008-08-06 18:43:47 +00:00
|
|
|
const char * const usage[],
|
2009-08-10 04:59:30 +00:00
|
|
|
const char *prefix,
|
2011-08-19 18:58:18 +00:00
|
|
|
struct commit *current_head,
|
2009-08-10 04:59:30 +00:00
|
|
|
struct wt_status *s)
|
2007-11-08 16:59:00 +00:00
|
|
|
{
|
2012-05-07 19:18:26 +00:00
|
|
|
argc = parse_options(argc, argv, prefix, options, usage, 0);
|
2013-06-24 18:41:40 +00:00
|
|
|
finalize_deferred_config(s);
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2008-08-27 06:13:13 +00:00
|
|
|
if (force_author && !strchr(force_author, '>'))
|
|
|
|
force_author = find_author_by_nickname(force_author);
|
|
|
|
|
2009-11-04 03:20:11 +00:00
|
|
|
if (force_author && renew_authorship)
|
2022-01-31 22:07:46 +00:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--reset-author", "--author");
|
2009-11-04 03:20:11 +00:00
|
|
|
|
2021-03-15 07:54:32 +00:00
|
|
|
if (logfile || have_option_m || use_message)
|
2007-12-23 03:25:37 +00:00
|
|
|
use_editor = 0;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
|
|
|
/* Sanity check options */
|
2011-08-19 18:58:18 +00:00
|
|
|
if (amend && !current_head)
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("You have nothing to amend."));
|
2012-04-30 15:33:13 +00:00
|
|
|
if (amend && whence != FROM_COMMIT) {
|
|
|
|
if (whence == FROM_MERGE)
|
|
|
|
die(_("You are in the middle of a merge -- cannot amend."));
|
2019-12-06 16:06:10 +00:00
|
|
|
else if (is_from_cherry_pick(whence))
|
2012-04-30 15:33:13 +00:00
|
|
|
die(_("You are in the middle of a cherry-pick -- cannot amend."));
|
2019-12-06 16:06:12 +00:00
|
|
|
else if (whence == FROM_REBASE_PICK)
|
|
|
|
die(_("You are in the middle of a rebase -- cannot amend."));
|
2012-04-30 15:33:13 +00:00
|
|
|
}
|
2010-11-02 19:59:11 +00:00
|
|
|
if (fixup_message && squash_message)
|
2022-01-31 22:07:46 +00:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--squash", "--fixup");
|
|
|
|
die_for_incompatible_opt4(!!use_message, "-C",
|
|
|
|
!!edit_message, "-c",
|
|
|
|
!!logfile, "-F",
|
|
|
|
!!fixup_message, "--fixup");
|
|
|
|
die_for_incompatible_opt4(have_option_m, "-m",
|
|
|
|
!!edit_message, "-c",
|
|
|
|
!!use_message, "-C",
|
|
|
|
!!logfile, "-F");
|
|
|
|
if (use_message || edit_message || logfile ||fixup_message || have_option_m)
|
2012-03-30 18:30:59 +00:00
|
|
|
template_file = NULL;
|
2007-11-08 16:59:00 +00:00
|
|
|
if (edit_message)
|
|
|
|
use_message = edit_message;
|
2010-11-02 19:59:09 +00:00
|
|
|
if (amend && !use_message && !fixup_message)
|
2007-11-08 16:59:00 +00:00
|
|
|
use_message = "HEAD";
|
2019-12-06 16:06:12 +00:00
|
|
|
if (!use_message && !is_from_cherry_pick(whence) &&
|
|
|
|
!is_from_rebase(whence) && renew_authorship)
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("--reset-author can be used only with -C, -c or --amend."));
|
2007-11-08 16:59:00 +00:00
|
|
|
if (use_message) {
|
2011-02-20 04:12:29 +00:00
|
|
|
use_message_buffer = read_commit_message(use_message);
|
|
|
|
if (!renew_authorship) {
|
|
|
|
author_message = use_message;
|
|
|
|
author_message_buffer = use_message_buffer;
|
|
|
|
}
|
|
|
|
}
|
2019-12-06 16:06:12 +00:00
|
|
|
if ((is_from_cherry_pick(whence) || whence == FROM_REBASE_PICK) &&
|
|
|
|
!renew_authorship) {
|
2011-02-20 04:12:29 +00:00
|
|
|
author_message = "CHERRY_PICK_HEAD";
|
|
|
|
author_message_buffer = read_commit_message(author_message);
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
|
|
|
|
2011-05-07 17:58:07 +00:00
|
|
|
if (patch_interactive)
|
|
|
|
interactive = 1;
|
|
|
|
|
2022-01-31 22:07:46 +00:00
|
|
|
die_for_incompatible_opt4(also, "-i/--include",
|
|
|
|
only, "-o/--only",
|
|
|
|
all, "-a/--all",
|
|
|
|
interactive, "--interactive/-p/--patch");
|
2021-03-15 07:54:32 +00:00
|
|
|
if (fixup_message) {
|
|
|
|
/*
|
|
|
|
* We limit --fixup's suboptions to only alpha characters.
|
|
|
|
* If the first character after a run of alpha is colon,
|
|
|
|
* then the part before the colon may be a known suboption
|
2021-03-15 07:54:33 +00:00
|
|
|
* name like `amend` or `reword`, or a misspelt suboption
|
|
|
|
* name. In either case, we treat it as
|
|
|
|
* --fixup=<suboption>:<arg>.
|
2021-03-15 07:54:32 +00:00
|
|
|
*
|
|
|
|
* Otherwise, we are dealing with --fixup=<commit>.
|
|
|
|
*/
|
|
|
|
char *p = fixup_message;
|
|
|
|
while (isalpha(*p))
|
|
|
|
p++;
|
|
|
|
if (p > fixup_message && *p == ':') {
|
|
|
|
*p = '\0';
|
|
|
|
fixup_commit = p + 1;
|
2021-03-15 07:54:33 +00:00
|
|
|
if (!strcmp("amend", fixup_message) ||
|
|
|
|
!strcmp("reword", fixup_message)) {
|
2021-03-15 07:54:32 +00:00
|
|
|
fixup_prefix = "amend";
|
|
|
|
allow_empty = 1;
|
2021-03-15 07:54:33 +00:00
|
|
|
if (*fixup_message == 'r') {
|
|
|
|
check_fixup_reword_options(argc, argv);
|
|
|
|
only = 1;
|
|
|
|
}
|
2021-03-15 07:54:32 +00:00
|
|
|
} else {
|
|
|
|
die(_("unknown option: --fixup=%s:%s"), fixup_message, fixup_commit);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
fixup_commit = fixup_message;
|
|
|
|
fixup_prefix = "fixup";
|
|
|
|
use_editor = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-08-14 21:40:30 +00:00
|
|
|
if (0 <= edit_flag)
|
|
|
|
use_editor = edit_flag;
|
|
|
|
|
2019-04-17 10:23:25 +00:00
|
|
|
cleanup_mode = get_cleanup_mode(cleanup_arg, use_editor);
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2009-08-08 06:31:57 +00:00
|
|
|
handle_untracked_files_arg(s);
|
2008-06-05 08:31:19 +00:00
|
|
|
|
2007-11-08 16:59:00 +00:00
|
|
|
if (all && argc > 0)
|
2019-03-20 10:29:06 +00:00
|
|
|
die(_("paths '%s ...' with -a does not make sense"),
|
|
|
|
argv[0]);
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2012-10-18 14:15:50 +00:00
|
|
|
if (status_format != STATUS_FORMAT_NONE)
|
2009-09-05 08:59:56 +00:00
|
|
|
dry_run = 1;
|
|
|
|
|
2007-11-08 16:59:00 +00:00
|
|
|
return argc;
|
|
|
|
}
|
|
|
|
|
2020-09-30 12:28:18 +00:00
|
|
|
static int dry_run_commit(const char **argv, const char *prefix,
|
2011-08-19 18:58:18 +00:00
|
|
|
const struct commit *current_head, struct wt_status *s)
|
2007-11-08 16:59:00 +00:00
|
|
|
{
|
2018-09-06 00:53:27 +00:00
|
|
|
int committable;
|
2009-08-08 06:03:36 +00:00
|
|
|
const char *index_file;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2020-09-30 12:28:18 +00:00
|
|
|
index_file = prepare_index(argv, prefix, current_head, 1);
|
2018-09-06 00:53:27 +00:00
|
|
|
committable = run_status(stdout, index_file, prefix, 0, s);
|
2009-08-08 06:03:36 +00:00
|
|
|
rollback_index_files();
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2018-09-06 00:53:27 +00:00
|
|
|
return committable ? 0 : 1;
|
2009-08-08 06:03:36 +00:00
|
|
|
}
|
|
|
|
|
2018-05-26 13:55:24 +00:00
|
|
|
define_list_config_array_extra(color_status_slots, {"added"});
|
|
|
|
|
2014-10-07 19:16:57 +00:00
|
|
|
static int parse_status_slot(const char *slot)
|
2009-08-10 06:12:19 +00:00
|
|
|
{
|
2018-05-26 13:55:21 +00:00
|
|
|
if (!strcasecmp(slot, "added"))
|
2009-08-10 06:12:19 +00:00
|
|
|
return WT_STATUS_UPDATED;
|
2018-05-26 13:55:21 +00:00
|
|
|
|
|
|
|
return LOOKUP_CONFIG(color_status_slots, slot);
|
2009-08-10 06:12:19 +00:00
|
|
|
}
|
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
static int git_status_config(const char *k, const char *v,
|
|
|
|
const struct config_context *ctx, void *cb)
|
2009-08-10 06:12:19 +00:00
|
|
|
{
|
|
|
|
struct wt_status *s = cb;
|
2014-10-04 18:54:50 +00:00
|
|
|
const char *slot_name;
|
2009-08-10 06:12:19 +00:00
|
|
|
|
2013-11-30 20:55:40 +00:00
|
|
|
if (starts_with(k, "column."))
|
2012-05-07 19:35:03 +00:00
|
|
|
return git_column_config(k, v, "status", &s->colopts);
|
2009-08-10 06:12:19 +00:00
|
|
|
if (!strcmp(k, "status.submodulesummary")) {
|
|
|
|
int is_bool;
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:27 +00:00
|
|
|
s->submodule_summary = git_config_bool_or_int(k, v, ctx->kvi,
|
|
|
|
&is_bool);
|
2009-08-10 06:12:19 +00:00
|
|
|
if (is_bool && s->submodule_summary)
|
|
|
|
s->submodule_summary = -1;
|
|
|
|
return 0;
|
|
|
|
}
|
2013-06-11 13:34:04 +00:00
|
|
|
if (!strcmp(k, "status.short")) {
|
|
|
|
if (git_config_bool(k, v))
|
2013-06-24 18:41:40 +00:00
|
|
|
status_deferred_config.status_format = STATUS_FORMAT_SHORT;
|
2013-06-11 13:34:04 +00:00
|
|
|
else
|
2013-06-24 18:41:40 +00:00
|
|
|
status_deferred_config.status_format = STATUS_FORMAT_NONE;
|
2013-06-11 13:34:04 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2013-06-11 13:34:05 +00:00
|
|
|
if (!strcmp(k, "status.branch")) {
|
2013-06-24 18:41:40 +00:00
|
|
|
status_deferred_config.show_branch = git_config_bool(k, v);
|
2013-06-11 13:34:05 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2019-06-18 20:21:25 +00:00
|
|
|
if (!strcmp(k, "status.aheadbehind")) {
|
|
|
|
status_deferred_config.ahead_behind = git_config_bool(k, v);
|
|
|
|
return 0;
|
|
|
|
}
|
2017-06-17 22:30:51 +00:00
|
|
|
if (!strcmp(k, "status.showstash")) {
|
|
|
|
s->show_stash = git_config_bool(k, v);
|
|
|
|
return 0;
|
|
|
|
}
|
2009-08-10 06:12:19 +00:00
|
|
|
if (!strcmp(k, "status.color") || !strcmp(k, "color.status")) {
|
2011-08-18 05:03:48 +00:00
|
|
|
s->use_color = git_config_colorbool(k, v);
|
2009-08-10 06:12:19 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2013-09-06 17:43:07 +00:00
|
|
|
if (!strcmp(k, "status.displaycommentprefix")) {
|
|
|
|
s->display_comment_prefix = git_config_bool(k, v);
|
|
|
|
return 0;
|
|
|
|
}
|
2014-10-04 18:54:50 +00:00
|
|
|
if (skip_prefix(k, "status.color.", &slot_name) ||
|
|
|
|
skip_prefix(k, "color.status.", &slot_name)) {
|
2014-10-20 19:23:48 +00:00
|
|
|
int slot = parse_status_slot(slot_name);
|
ignore unknown color configuration
When parsing the config file, if there is a value that is
syntactically correct but unused, we generally ignore it.
This lets non-core porcelains store arbitrary information in
the config file, and it means that configuration files can
be shared between new and old versions of git (the old
versions might simply ignore certain configuration).
The one exception to this is color configuration; if we
encounter a color.{diff,branch,status}.$slot variable, we
die if it is not one of the recognized slots (presumably as
a safety valve for user misconfiguration). This behavior
has existed since 801235c (diff --color: use
$GIT_DIR/config, 2006-06-24), but hasn't yet caused a
problem. No porcelain has wanted to store extra colors, and
we once a color area (like color.diff) has been introduced,
we've never changed the set of color slots.
However, that changed recently with the addition of
color.diff.func. Now a user with color.diff.func in their
config can no longer freely switch between v1.6.6 and older
versions; the old versions will complain about the existence
of the variable.
This patch loosens the check to match the rest of
git-config; unknown color slots are simply ignored. This
doesn't fix this particular problem, as the older version
(without this patch) is the problem, but it at least
prevents it from happening again in the future.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-12 12:25:24 +00:00
|
|
|
if (slot < 0)
|
|
|
|
return 0;
|
2009-08-10 06:12:19 +00:00
|
|
|
if (!v)
|
|
|
|
return config_error_nonbool(k);
|
2014-10-07 19:33:09 +00:00
|
|
|
return color_parse(v, s->color_palette[slot]);
|
2009-08-10 06:12:19 +00:00
|
|
|
}
|
|
|
|
if (!strcmp(k, "status.relativepaths")) {
|
|
|
|
s->relative_paths = git_config_bool(k, v);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (!strcmp(k, "status.showuntrackedfiles")) {
|
|
|
|
if (!v)
|
|
|
|
return config_error_nonbool(k);
|
|
|
|
else if (!strcmp(v, "no"))
|
|
|
|
s->show_untracked_files = SHOW_NO_UNTRACKED_FILES;
|
|
|
|
else if (!strcmp(v, "normal"))
|
|
|
|
s->show_untracked_files = SHOW_NORMAL_UNTRACKED_FILES;
|
|
|
|
else if (!strcmp(v, "all"))
|
|
|
|
s->show_untracked_files = SHOW_ALL_UNTRACKED_FILES;
|
|
|
|
else
|
2011-02-22 23:41:44 +00:00
|
|
|
return error(_("Invalid untracked files mode '%s'"), v);
|
2009-08-10 06:12:19 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2018-05-11 15:38:58 +00:00
|
|
|
if (!strcmp(k, "diff.renamelimit")) {
|
|
|
|
if (s->rename_limit == -1)
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:27 +00:00
|
|
|
s->rename_limit = git_config_int(k, v, ctx->kvi);
|
2018-05-11 15:38:58 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (!strcmp(k, "status.renamelimit")) {
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:27 +00:00
|
|
|
s->rename_limit = git_config_int(k, v, ctx->kvi);
|
2018-05-11 15:38:58 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (!strcmp(k, "diff.renames")) {
|
|
|
|
if (s->detect_rename == -1)
|
|
|
|
s->detect_rename = git_config_rename(k, v);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (!strcmp(k, "status.renames")) {
|
|
|
|
s->detect_rename = git_config_rename(k, v);
|
|
|
|
return 0;
|
|
|
|
}
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
return git_diff_ui_config(k, v, ctx, NULL);
|
2009-08-10 06:12:19 +00:00
|
|
|
}
|
|
|
|
|
2009-08-08 06:03:36 +00:00
|
|
|
int cmd_status(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
2018-05-11 15:38:58 +00:00
|
|
|
static int no_renames = -1;
|
|
|
|
static const char *rename_score_arg = (const char *)-1;
|
2012-05-07 19:18:26 +00:00
|
|
|
static struct wt_status s;
|
2018-09-15 17:56:04 +00:00
|
|
|
unsigned int progress_flag = 0;
|
2010-04-02 21:44:21 +00:00
|
|
|
int fd;
|
2017-02-20 00:10:14 +00:00
|
|
|
struct object_id oid;
|
2009-08-15 09:27:39 +00:00
|
|
|
static struct option builtin_status_options[] = {
|
2012-08-20 12:32:37 +00:00
|
|
|
OPT__VERBOSE(&verbose, N_("be verbose")),
|
2009-09-05 08:54:14 +00:00
|
|
|
OPT_SET_INT('s', "short", &status_format,
|
2012-08-20 12:32:37 +00:00
|
|
|
N_("show status concisely"), STATUS_FORMAT_SHORT),
|
2013-06-24 18:41:40 +00:00
|
|
|
OPT_BOOL('b', "branch", &s.show_branch,
|
|
|
|
N_("show branch information")),
|
2017-06-17 22:30:51 +00:00
|
|
|
OPT_BOOL(0, "show-stash", &s.show_stash,
|
|
|
|
N_("show stash information")),
|
2018-01-09 18:50:16 +00:00
|
|
|
OPT_BOOL(0, "ahead-behind", &s.ahead_behind_flags,
|
|
|
|
N_("compute full ahead/behind values")),
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 08:36:28 +00:00
|
|
|
OPT_CALLBACK_F(0, "porcelain", &status_format,
|
2016-08-05 22:00:28 +00:00
|
|
|
N_("version"), N_("machine-readable output"),
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 08:36:28 +00:00
|
|
|
PARSE_OPT_OPTARG, opt_parse_porcelain),
|
2012-10-18 14:15:50 +00:00
|
|
|
OPT_SET_INT(0, "long", &status_format,
|
|
|
|
N_("show status in long format (default)"),
|
|
|
|
STATUS_FORMAT_LONG),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('z', "null", &s.null_termination,
|
|
|
|
N_("terminate entries with NUL")),
|
2009-08-08 06:31:57 +00:00
|
|
|
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg,
|
2012-08-20 12:32:37 +00:00
|
|
|
N_("mode"),
|
|
|
|
N_("show untracked files, optional modes: all, normal, no. (Default: all)"),
|
2009-08-08 06:31:57 +00:00
|
|
|
PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
|
status: add option to show ignored files differently
Teach the status command more flexibility in how ignored files are
reported. Currently, the reporting of ignored files and untracked
files are linked. You cannot control how ignored files are reported
independently of how untracked files are reported (i.e. `all` vs
`normal`). This makes it impossible to show untracked files with the
`all` option, but show ignored files with the `normal` option.
This work 1) adds the ability to control the reporting of ignored
files independently of untracked files and 2) introduces the concept
of status reporting ignored paths that explicitly match an ignored
pattern. There are 2 benefits to these changes: 1) if a consumer needs
all untracked files but not all ignored files, there is a performance
benefit to not scanning all contents of an ignored directory and 2)
returning ignored files that explicitly match a path allow a consumer
to make more informed decisions about when a status result might be
stale.
This commit implements --ignored=matching with --untracked-files=all.
The following commit will implement --ignored=matching with
--untracked=files=normal.
As an example of where this flexibility could be useful is that our
application (Visual Studio) runs the status command and presents the
output. It shows all untracked files individually (e.g. using the
'--untracked-files==all' option), and would like to know about which
paths are ignored. It uses information about ignored paths to make
decisions about when the status result might have changed.
Additionally, many projects place build output into directories inside
a repository's working directory (e.g. in "bin/" and "obj/"
directories). Normal usage is to explicitly ignore these 2 directory
names in the .gitignore file (rather than or in addition to the *.obj
pattern).If an application could know that these directories are
explicitly ignored, it could infer that all contents are ignored as
well and make better informed decisions about files in these
directories. It could infer that any changes under these paths would
not affect the output of status. Additionally, there can be a
significant performance benefit by avoiding scanning through ignored
directories.
When status is set to report matching ignored files, it has the
following behavior. Ignored files and directories that explicitly
match an exclude pattern are reported. If an ignored directory matches
an exclude pattern, then the path of the directory is returned. If a
directory does not match an exclude pattern, but all of its contents
are ignored, then the contained files are reported instead of the
directory.
Signed-off-by: Jameson Miller <jamill@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-30 17:21:37 +00:00
|
|
|
{ OPTION_STRING, 0, "ignored", &ignored_arg,
|
|
|
|
N_("mode"),
|
|
|
|
N_("show ignored files, optional modes: traditional, matching, no. (Default: traditional)"),
|
|
|
|
PARSE_OPT_OPTARG, NULL, (intptr_t)"traditional" },
|
2012-08-20 12:32:37 +00:00
|
|
|
{ OPTION_STRING, 0, "ignore-submodules", &ignore_submodule_arg, N_("when"),
|
|
|
|
N_("ignore changes to submodules, optional when: all, dirty, untracked. (Default: all)"),
|
2010-06-25 14:56:47 +00:00
|
|
|
PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
|
2012-08-20 12:32:04 +00:00
|
|
|
OPT_COLUMN(0, "column", &s.colopts, N_("list untracked files in columns")),
|
2018-05-11 15:38:58 +00:00
|
|
|
OPT_BOOL(0, "no-renames", &no_renames, N_("do not detect renames")),
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 08:36:28 +00:00
|
|
|
OPT_CALLBACK_F('M', "find-renames", &rename_score_arg,
|
2018-05-11 15:38:58 +00:00
|
|
|
N_("n"), N_("detect renames, optionally set similarity index"),
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 08:36:28 +00:00
|
|
|
PARSE_OPT_OPTARG | PARSE_OPT_NONEG, opt_parse_rename_score),
|
2009-08-08 06:31:57 +00:00
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
|
2010-10-22 06:45:47 +00:00
|
|
|
if (argc == 2 && !strcmp(argv[1], "-h"))
|
|
|
|
usage_with_options(builtin_status_usage, builtin_status_options);
|
|
|
|
|
2021-07-14 13:12:37 +00:00
|
|
|
prepare_repo_settings(the_repository);
|
|
|
|
the_repository->settings.command_requires_full_index = 0;
|
|
|
|
|
2013-09-12 10:50:04 +00:00
|
|
|
status_init_config(&s, git_status_config);
|
2009-08-08 06:31:57 +00:00
|
|
|
argc = parse_options(argc, argv, prefix,
|
2009-08-15 09:27:39 +00:00
|
|
|
builtin_status_options,
|
|
|
|
builtin_status_usage, 0);
|
2012-05-07 19:35:03 +00:00
|
|
|
finalize_colopts(&s.colopts, -1);
|
2013-06-24 18:41:40 +00:00
|
|
|
finalize_deferred_config(&s);
|
2011-05-26 20:43:21 +00:00
|
|
|
|
2009-08-08 06:31:57 +00:00
|
|
|
handle_untracked_files_arg(&s);
|
status: add option to show ignored files differently
Teach the status command more flexibility in how ignored files are
reported. Currently, the reporting of ignored files and untracked
files are linked. You cannot control how ignored files are reported
independently of how untracked files are reported (i.e. `all` vs
`normal`). This makes it impossible to show untracked files with the
`all` option, but show ignored files with the `normal` option.
This work 1) adds the ability to control the reporting of ignored
files independently of untracked files and 2) introduces the concept
of status reporting ignored paths that explicitly match an ignored
pattern. There are 2 benefits to these changes: 1) if a consumer needs
all untracked files but not all ignored files, there is a performance
benefit to not scanning all contents of an ignored directory and 2)
returning ignored files that explicitly match a path allow a consumer
to make more informed decisions about when a status result might be
stale.
This commit implements --ignored=matching with --untracked-files=all.
The following commit will implement --ignored=matching with
--untracked=files=normal.
As an example of where this flexibility could be useful is that our
application (Visual Studio) runs the status command and presents the
output. It shows all untracked files individually (e.g. using the
'--untracked-files==all' option), and would like to know about which
paths are ignored. It uses information about ignored paths to make
decisions about when the status result might have changed.
Additionally, many projects place build output into directories inside
a repository's working directory (e.g. in "bin/" and "obj/"
directories). Normal usage is to explicitly ignore these 2 directory
names in the .gitignore file (rather than or in addition to the *.obj
pattern).If an application could know that these directories are
explicitly ignored, it could infer that all contents are ignored as
well and make better informed decisions about files in these
directories. It could infer that any changes under these paths would
not affect the output of status. Additionally, there can be a
significant performance benefit by avoiding scanning through ignored
directories.
When status is set to report matching ignored files, it has the
following behavior. Ignored files and directories that explicitly
match an exclude pattern are reported. If an ignored directory matches
an exclude pattern, then the path of the directory is returned. If a
directory does not match an exclude pattern, but all of its contents
are ignored, then the contained files are reported instead of the
directory.
Signed-off-by: Jameson Miller <jamill@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-30 17:21:37 +00:00
|
|
|
handle_ignored_arg(&s);
|
|
|
|
|
|
|
|
if (s.show_ignored_mode == SHOW_MATCHING_IGNORED &&
|
|
|
|
s.show_untracked_files == SHOW_NO_UNTRACKED_FILES)
|
|
|
|
die(_("Unsupported combination of ignored and untracked-files arguments"));
|
|
|
|
|
2013-07-14 08:35:39 +00:00
|
|
|
parse_pathspec(&s.pathspec, 0,
|
|
|
|
PATHSPEC_PREFER_FULL,
|
|
|
|
prefix, argv);
|
2009-08-08 06:31:57 +00:00
|
|
|
|
2018-09-15 17:56:04 +00:00
|
|
|
if (status_format != STATUS_FORMAT_PORCELAIN &&
|
|
|
|
status_format != STATUS_FORMAT_PORCELAIN_V2)
|
|
|
|
progress_flag = REFRESH_PROGRESS;
|
2019-01-12 02:13:26 +00:00
|
|
|
repo_read_index(the_repository);
|
2018-09-15 17:56:04 +00:00
|
|
|
refresh_index(&the_index,
|
|
|
|
REFRESH_QUIET|REFRESH_UNMERGED|progress_flag,
|
|
|
|
&s.pathspec, NULL, NULL);
|
2010-04-02 21:44:21 +00:00
|
|
|
|
git: add --no-optional-locks option
Some tools like IDEs or fancy editors may periodically run
commands like "git status" in the background to keep track
of the state of the repository. Some of these commands may
refresh the index and write out the result in an
opportunistic way: if they can get the index lock, then they
update the on-disk index with any updates they find. And if
not, then their in-core refresh is lost and just has to be
recomputed by the next caller.
But taking the index lock may conflict with other operations
in the repository. Especially ones that the user is doing
themselves, which _aren't_ opportunistic. In other words,
"git status" knows how to back off when somebody else is
holding the lock, but other commands don't know that status
would be happy to drop the lock if somebody else wanted it.
There are a couple possible solutions:
1. Have some kind of "pseudo-lock" that allows other
commands to tell status that they want the lock.
This is likely to be complicated and error-prone to
implement (and maybe even impossible with just
dotlocks to work from, as it requires some
inter-process communication).
2. Avoid background runs of commands like "git status"
that want to do opportunistic updates, preferring
instead plumbing like diff-files, etc.
This is awkward for a couple of reasons. One is that
"status --porcelain" reports a lot more about the
repository state than is available from individual
plumbing commands. And two is that we actually _do_
want to see the refreshed index. We just don't want to
take a lock or write out the result. Whereas commands
like diff-files expect us to refresh the index
separately and write it to disk so that they can depend
on the result. But that write is exactly what we're
trying to avoid.
3. Ask "status" not to lock or write the index.
This is easy to implement. The big downside is that any
work done in refreshing the index for such a call is
lost when the process exits. So a background process
may end up re-hashing a changed file multiple times
until the user runs a command that does an index
refresh themselves.
This patch implements the option 3. The idea (and the test)
is largely stolen from a Git for Windows patch by Johannes
Schindelin, 67e5ce7f63 (status: offer *not* to lock the
index and update it, 2016-08-12). The twist here is that
instead of making this an option to "git status", it becomes
a "git" option and matching environment variable.
The reason there is two-fold:
1. An environment variable is carried through to
sub-processes. And whether an invocation is a
background process or not should apply to the whole
process tree. So you could do "git --no-optional-locks
foo", and if "foo" is a script or alias that calls
"status", you'll still get the effect.
2. There may be other programs that want the same
treatment.
I've punted here on finding more callers to convert,
since "status" is the obvious one to call as a repeated
background job. But "git diff"'s opportunistic refresh
of the index may be a good candidate.
The test is taken from 67e5ce7f63, and it's worth repeating
Johannes's explanation:
Note that the regression test added in this commit does
not *really* verify that no index.lock file was written;
that test is not possible in a portable way. Instead, we
verify that .git/index is rewritten *only* when `git
status` is run without `--no-optional-locks`.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27 06:54:30 +00:00
|
|
|
if (use_optional_locks())
|
2022-11-19 13:07:38 +00:00
|
|
|
fd = repo_hold_locked_index(the_repository, &index_lock, 0);
|
git: add --no-optional-locks option
Some tools like IDEs or fancy editors may periodically run
commands like "git status" in the background to keep track
of the state of the repository. Some of these commands may
refresh the index and write out the result in an
opportunistic way: if they can get the index lock, then they
update the on-disk index with any updates they find. And if
not, then their in-core refresh is lost and just has to be
recomputed by the next caller.
But taking the index lock may conflict with other operations
in the repository. Especially ones that the user is doing
themselves, which _aren't_ opportunistic. In other words,
"git status" knows how to back off when somebody else is
holding the lock, but other commands don't know that status
would be happy to drop the lock if somebody else wanted it.
There are a couple possible solutions:
1. Have some kind of "pseudo-lock" that allows other
commands to tell status that they want the lock.
This is likely to be complicated and error-prone to
implement (and maybe even impossible with just
dotlocks to work from, as it requires some
inter-process communication).
2. Avoid background runs of commands like "git status"
that want to do opportunistic updates, preferring
instead plumbing like diff-files, etc.
This is awkward for a couple of reasons. One is that
"status --porcelain" reports a lot more about the
repository state than is available from individual
plumbing commands. And two is that we actually _do_
want to see the refreshed index. We just don't want to
take a lock or write out the result. Whereas commands
like diff-files expect us to refresh the index
separately and write it to disk so that they can depend
on the result. But that write is exactly what we're
trying to avoid.
3. Ask "status" not to lock or write the index.
This is easy to implement. The big downside is that any
work done in refreshing the index for such a call is
lost when the process exits. So a background process
may end up re-hashing a changed file multiple times
until the user runs a command that does an index
refresh themselves.
This patch implements the option 3. The idea (and the test)
is largely stolen from a Git for Windows patch by Johannes
Schindelin, 67e5ce7f63 (status: offer *not* to lock the
index and update it, 2016-08-12). The twist here is that
instead of making this an option to "git status", it becomes
a "git" option and matching environment variable.
The reason there is two-fold:
1. An environment variable is carried through to
sub-processes. And whether an invocation is a
background process or not should apply to the whole
process tree. So you could do "git --no-optional-locks
foo", and if "foo" is a script or alias that calls
"status", you'll still get the effect.
2. There may be other programs that want the same
treatment.
I've punted here on finding more callers to convert,
since "status" is the obvious one to call as a repeated
background job. But "git diff"'s opportunistic refresh
of the index may be a good candidate.
The test is taken from 67e5ce7f63, and it's worth repeating
Johannes's explanation:
Note that the regression test added in this commit does
not *really* verify that no index.lock file was written;
that test is not possible in a portable way. Instead, we
verify that .git/index is rewritten *only* when `git
status` is run without `--no-optional-locks`.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27 06:54:30 +00:00
|
|
|
else
|
|
|
|
fd = -1;
|
2010-04-02 21:44:21 +00:00
|
|
|
|
2023-03-28 13:58:46 +00:00
|
|
|
s.is_initial = repo_get_oid(the_repository, s.reference, &oid) ? 1 : 0;
|
2016-08-11 14:45:59 +00:00
|
|
|
if (!s.is_initial)
|
2019-08-18 20:04:21 +00:00
|
|
|
oidcpy(&s.oid_commit, &oid);
|
2016-08-11 14:45:59 +00:00
|
|
|
|
2010-06-25 14:56:47 +00:00
|
|
|
s.ignore_submodule_arg = ignore_submodule_arg;
|
2016-08-05 22:00:27 +00:00
|
|
|
s.status_format = status_format;
|
|
|
|
s.verbose = verbose;
|
2018-05-11 15:38:58 +00:00
|
|
|
if (no_renames != -1)
|
|
|
|
s.detect_rename = !no_renames;
|
|
|
|
if ((intptr_t)rename_score_arg != -1) {
|
|
|
|
if (s.detect_rename < DIFF_DETECT_RENAME)
|
|
|
|
s.detect_rename = DIFF_DETECT_RENAME;
|
|
|
|
if (rename_score_arg)
|
|
|
|
s.rename_score = parse_rename_score(&rename_score_arg);
|
|
|
|
}
|
2016-08-05 22:00:27 +00:00
|
|
|
|
2009-08-08 06:31:57 +00:00
|
|
|
wt_status_collect(&s);
|
|
|
|
|
2015-03-08 10:12:41 +00:00
|
|
|
if (0 <= fd)
|
2019-01-12 02:13:27 +00:00
|
|
|
repo_update_index_if_able(the_repository, &index_lock);
|
2015-03-08 10:12:41 +00:00
|
|
|
|
2009-12-07 05:26:25 +00:00
|
|
|
if (s.relative_paths)
|
|
|
|
s.prefix = prefix;
|
2009-01-08 18:53:05 +00:00
|
|
|
|
2016-08-05 22:00:27 +00:00
|
|
|
wt_status_print(&s);
|
2018-09-30 14:12:45 +00:00
|
|
|
wt_status_collect_free_buffers(&s);
|
|
|
|
|
2009-08-08 06:31:57 +00:00
|
|
|
return 0;
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
static int git_commit_config(const char *k, const char *v,
|
|
|
|
const struct config_context *ctx, void *cb)
|
2007-11-08 16:59:00 +00:00
|
|
|
{
|
2009-08-10 04:59:30 +00:00
|
|
|
struct wt_status *s = cb;
|
|
|
|
|
2008-07-05 05:24:40 +00:00
|
|
|
if (!strcmp(k, "commit.template"))
|
2009-11-17 17:24:25 +00:00
|
|
|
return git_config_pathname(&template_file, k, v);
|
2009-12-07 22:45:27 +00:00
|
|
|
if (!strcmp(k, "commit.status")) {
|
|
|
|
include_status = git_config_bool(k, v);
|
|
|
|
return 0;
|
|
|
|
}
|
2013-01-10 17:45:59 +00:00
|
|
|
if (!strcmp(k, "commit.cleanup"))
|
|
|
|
return git_config_string(&cleanup_arg, k, v);
|
2013-11-04 23:14:41 +00:00
|
|
|
if (!strcmp(k, "commit.gpgsign")) {
|
|
|
|
sign_commit = git_config_bool(k, v) ? "" : NULL;
|
|
|
|
return 0;
|
|
|
|
}
|
2016-05-05 09:50:02 +00:00
|
|
|
if (!strcmp(k, "commit.verbose")) {
|
|
|
|
int is_bool;
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:27 +00:00
|
|
|
config_commit_verbose = git_config_bool_or_int(k, v, ctx->kvi,
|
|
|
|
&is_bool);
|
2016-05-05 09:50:02 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2007-11-08 16:59:00 +00:00
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
return git_status_config(k, v, ctx, s);
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int cmd_commit(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
2012-05-07 19:18:26 +00:00
|
|
|
static struct wt_status s;
|
|
|
|
static struct option builtin_commit_options[] = {
|
2012-08-20 12:32:04 +00:00
|
|
|
OPT__QUIET(&quiet, N_("suppress summary after successful commit")),
|
|
|
|
OPT__VERBOSE(&verbose, N_("show diff in commit message template")),
|
|
|
|
|
|
|
|
OPT_GROUP(N_("Commit message options")),
|
|
|
|
OPT_FILENAME('F', "file", &logfile, N_("read message from file")),
|
|
|
|
OPT_STRING(0, "author", &force_author, N_("author"), N_("override author for commit")),
|
|
|
|
OPT_STRING(0, "date", &force_date, N_("date"), N_("override date for commit")),
|
|
|
|
OPT_CALLBACK('m', "message", &message, N_("message"), N_("commit message"), opt_parse_m),
|
|
|
|
OPT_STRING('c', "reedit-message", &edit_message, N_("commit"), N_("reuse and edit message from specified commit")),
|
|
|
|
OPT_STRING('C', "reuse-message", &use_message, N_("commit"), N_("reuse message from specified commit")),
|
2021-03-15 07:54:32 +00:00
|
|
|
/*
|
2021-03-15 07:54:33 +00:00
|
|
|
* TRANSLATORS: Leave "[(amend|reword):]" as-is,
|
|
|
|
* and only translate <commit>.
|
2021-03-15 07:54:32 +00:00
|
|
|
*/
|
2021-03-15 07:54:33 +00:00
|
|
|
OPT_STRING(0, "fixup", &fixup_message, N_("[(amend|reword):]commit"), N_("use autosquash formatted message to fixup or amend/reword specified commit")),
|
2012-08-20 12:32:04 +00:00
|
|
|
OPT_STRING(0, "squash", &squash_message, N_("commit"), N_("use autosquash formatted message to squash specified commit")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL(0, "reset-author", &renew_authorship, N_("the commit is authored by me now (used with -C/-c/--amend)")),
|
commit: avoid writing to global in option callback
The callback function for --trailer writes directly to the global
trailer_args and ignores opt->value completely. This is OK, since that's
where we expect to find the value. But it does mean the option
declaration isn't as clear. E.g., we have:
OPT_BOOL(0, "reset-author", &renew_authorship, ...),
OPT_CALLBACK_F(0, "trailer", NULL, ..., opt_pass_trailer)
In the first one we can see where the result will be stored, but in the
second, we get only NULL, and you have to go read the callback.
Let's pass &trailer_args, and use it in the callback. As a bonus, this
silences a -Wunused-parameter warning.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-06 13:11:31 +00:00
|
|
|
OPT_CALLBACK_F(0, "trailer", &trailer_args, N_("trailer"), N_("add custom trailer(s)"), PARSE_OPT_NONEG, opt_pass_trailer),
|
Documentation: stylistically normalize references to Signed-off-by:
Ted reported an old typo in the git-commit.txt and merge-options.txt.
Namely, the phrase "Signed-off-by line" was used without either a
definite nor indefinite article.
Upon examination, it seems that the documentation (including items in
Documentation/, but also option help strings) have been quite
inconsistent on usage when referring to `Signed-off-by`.
First, very few places used a definite or indefinite article with the
phrase "Signed-off-by line", but that was the initial typo that led
to this investigation. So, normalize using either an indefinite or
definite article consistently.
The original phrasing, in Commit 3f971fc425b (Documentation updates,
2005-08-14), is "Add Signed-off-by line". Commit 6f855371a53 (Add
--signoff, --check, and long option-names. 2005-12-09) switched to
using "Add `Signed-off-by:` line", but didn't normalize the former
commit to match. Later commits seem to have cut and pasted from one
or the other, which is likely how the usage became so inconsistent.
Junio stated on the git mailing list in
<xmqqy2k1dfoh.fsf@gitster.c.googlers.com> a preference to leave off
the colon. Thus, prefer `Signed-off-by` (with backticks) for the
documentation files and Signed-off-by (without backticks) for option
help strings.
Additionally, Junio argued that "trailer" is now the standard term to
refer to `Signed-off-by`, saying that "becomes plenty clear that we
are not talking about any random line in the log message". As such,
prefer "trailer" over "line" anywhere the former word fits.
However, leave alone those few places in documentation that use
Signed-off-by to refer to the process (rather than the specific
trailer), or in places where mail headers are generally discussed in
comparison with Signed-off-by.
Reported-by: "Theodore Y. Ts'o" <tytso@mit.edu>
Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>
Acked-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20 01:03:55 +00:00
|
|
|
OPT_BOOL('s', "signoff", &signoff, N_("add a Signed-off-by trailer")),
|
2012-08-20 12:32:04 +00:00
|
|
|
OPT_FILENAME('t', "template", &template_file, N_("use specified template file")),
|
|
|
|
OPT_BOOL('e', "edit", &edit_flag, N_("force edit of commit")),
|
2019-04-17 10:23:26 +00:00
|
|
|
OPT_CLEANUP(&cleanup_arg),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL(0, "status", &include_status, N_("include status in commit message template")),
|
2014-03-23 22:58:12 +00:00
|
|
|
{ OPTION_STRING, 'S', "gpg-sign", &sign_commit, N_("key-id"),
|
2012-08-20 12:32:04 +00:00
|
|
|
N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
|
2012-05-07 19:18:26 +00:00
|
|
|
/* end commit message options */
|
|
|
|
|
2012-08-20 12:32:04 +00:00
|
|
|
OPT_GROUP(N_("Commit contents options")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('a', "all", &all, N_("commit all changed files")),
|
|
|
|
OPT_BOOL('i', "include", &also, N_("add specified files to index for commit")),
|
|
|
|
OPT_BOOL(0, "interactive", &interactive, N_("interactively add files")),
|
|
|
|
OPT_BOOL('p', "patch", &patch_interactive, N_("interactively add changes")),
|
|
|
|
OPT_BOOL('o', "only", &only, N_("commit only specified files")),
|
2016-07-26 14:00:15 +00:00
|
|
|
OPT_BOOL('n', "no-verify", &no_verify, N_("bypass pre-commit and commit-msg hooks")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL(0, "dry-run", &dry_run, N_("show what would be committed")),
|
2012-08-20 12:32:04 +00:00
|
|
|
OPT_SET_INT(0, "short", &status_format, N_("show status concisely"),
|
2012-05-07 19:18:26 +00:00
|
|
|
STATUS_FORMAT_SHORT),
|
2013-06-24 18:41:40 +00:00
|
|
|
OPT_BOOL(0, "branch", &s.show_branch, N_("show branch information")),
|
2018-01-09 18:50:16 +00:00
|
|
|
OPT_BOOL(0, "ahead-behind", &s.ahead_behind_flags,
|
|
|
|
N_("compute full ahead/behind values")),
|
2012-05-07 19:18:26 +00:00
|
|
|
OPT_SET_INT(0, "porcelain", &status_format,
|
2012-08-20 12:32:04 +00:00
|
|
|
N_("machine-readable output"), STATUS_FORMAT_PORCELAIN),
|
2012-10-18 14:15:50 +00:00
|
|
|
OPT_SET_INT(0, "long", &status_format,
|
|
|
|
N_("show status in long format (default)"),
|
|
|
|
STATUS_FORMAT_LONG),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('z', "null", &s.null_termination,
|
|
|
|
N_("terminate entries with NUL")),
|
|
|
|
OPT_BOOL(0, "amend", &amend, N_("amend previous commit")),
|
|
|
|
OPT_BOOL(0, "no-post-rewrite", &no_post_rewrite, N_("bypass post-rewrite hook")),
|
2012-08-20 12:32:04 +00:00
|
|
|
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, N_("mode"), N_("show untracked files, optional modes: all, normal, no. (Default: all)"), PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
|
2019-11-19 16:48:55 +00:00
|
|
|
OPT_PATHSPEC_FROM_FILE(&pathspec_from_file),
|
|
|
|
OPT_PATHSPEC_FILE_NUL(&pathspec_file_nul),
|
2012-05-07 19:18:26 +00:00
|
|
|
/* end commit contents options */
|
|
|
|
|
2013-08-03 11:51:18 +00:00
|
|
|
OPT_HIDDEN_BOOL(0, "allow-empty", &allow_empty,
|
|
|
|
N_("ok to record an empty change")),
|
|
|
|
OPT_HIDDEN_BOOL(0, "allow-empty-message", &allow_empty_message,
|
|
|
|
N_("ok to record a change with an empty message")),
|
2012-05-07 19:18:26 +00:00
|
|
|
|
|
|
|
OPT_END()
|
|
|
|
};
|
|
|
|
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2010-12-21 01:00:36 +00:00
|
|
|
struct strbuf author_ident = STRBUF_INIT;
|
2007-11-08 16:59:00 +00:00
|
|
|
const char *index_file, *reflog_msg;
|
2017-02-20 00:10:14 +00:00
|
|
|
struct object_id oid;
|
2016-10-29 12:55:36 +00:00
|
|
|
struct commit_list *parents = NULL;
|
builtin-commit: use reduce_heads() only when appropriate
Since commit 6bb6b034 (builtin-commit: use commit_tree(), 2008-09-10),
builtin-commit performs a reduce_heads() unconditionally. However,
it's not always needed, and in some cases even harmful.
reduce_heads() is not needed for the initial commit or for an
"ordinary" commit, because they don't have any or have only one
parent, respectively.
reduce_heads() must be avoided when 'git commit' is run after a 'git
merge --no-ff --no-commit', otherwise it will turn the
non-fast-forward merge into fast-forward. For the same reason,
reduce_heads() must be avoided when amending such a merge commit.
To resolve this issue, 'git merge' will write info about whether
fast-forward is allowed or not to $GIT_DIR/MERGE_MODE. Based on this
info, 'git commit' will only perform reduce_heads() when it's
committing a merge and fast-forward is enabled.
Also add test cases to ensure that non-fast-forward merges are
committed and amended properly.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-03 12:04:47 +00:00
|
|
|
struct stat statbuf;
|
2011-08-19 18:58:18 +00:00
|
|
|
struct commit *current_head = NULL;
|
2011-11-08 23:38:07 +00:00
|
|
|
struct commit_extra_header *extra = NULL;
|
2014-04-16 22:34:19 +00:00
|
|
|
struct strbuf err = STRBUF_INIT;
|
commit: fix "author_ident" leak
Since 4c28e4ada03 (commit: die before asking to edit the log
message, 2010-12-20), we have been "leaking" the "author_ident" when
prepare_to_commit() fails. Instead of returning from right there,
introduce an exit status variable and jump to the clean-up label
at the end.
Instead of explicitly releasing the resource with strbuf_release(),
mark the variable with UNLEAK() at the end, together with two other
variables that are already marked as such. If this were in a
utility function that is called number of times, but these are
different, we should explicitly release resources that grow
proportionally to the size of the problem being solved, but
cmd_commit() is like main() and there is no point in spending extra
cycles to release individual pieces of resource at the end, just
before process exit will clean everything for us for free anyway.
This fixes a leak demonstrated by e.g. "t3505-cherry-pick-empty.sh",
but unfortunately we cannot mark it or other affected tests as passing
now with "TEST_PASSES_SANITIZE_LEAK=true" as we'll need to fix many
other memory leaks before doing so.
Incidentally there are two tests that always passes the leak checker
with or without this change. Mark them as such.
This is based on an earlier patch by Ævar, but takes a different
approach that is more maintainable.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-12 22:51:07 +00:00
|
|
|
int ret = 0;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2010-10-22 06:45:47 +00:00
|
|
|
if (argc == 2 && !strcmp(argv[1], "-h"))
|
|
|
|
usage_with_options(builtin_commit_usage, builtin_commit_options);
|
|
|
|
|
2021-06-29 02:13:04 +00:00
|
|
|
prepare_repo_settings(the_repository);
|
|
|
|
the_repository->settings.command_requires_full_index = 0;
|
|
|
|
|
2013-09-12 10:50:04 +00:00
|
|
|
status_init_config(&s, git_commit_config);
|
2017-06-21 18:16:14 +00:00
|
|
|
s.commit_template = 1;
|
2013-06-24 12:45:12 +00:00
|
|
|
status_format = STATUS_FORMAT_NONE; /* Ignore status.short */
|
2012-05-07 19:35:03 +00:00
|
|
|
s.colopts = 0;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2023-03-28 13:58:46 +00:00
|
|
|
if (repo_get_oid(the_repository, "HEAD", &oid))
|
2011-08-19 18:58:18 +00:00
|
|
|
current_head = NULL;
|
|
|
|
else {
|
Convert lookup_commit* to struct object_id
Convert lookup_commit, lookup_commit_or_die,
lookup_commit_reference, and lookup_commit_reference_gently to take
struct object_id arguments.
Introduce a temporary in parse_object buffer in order to convert this
function. This is required since in order to convert parse_object and
parse_object_buffer, lookup_commit_reference_gently and
lookup_commit_or_die would need to be converted. Not introducing a
temporary would therefore require that lookup_commit_or_die take a
struct object_id *, but lookup_commit would take unsigned char *,
leaving a confusing and hard-to-use interface.
parse_object_buffer will lose this temporary in a later patch.
This commit was created with manual changes to commit.c, commit.h, and
object.c, plus the following semantic patch:
@@
expression E1, E2;
@@
- lookup_commit_reference_gently(E1.hash, E2)
+ lookup_commit_reference_gently(&E1, E2)
@@
expression E1, E2;
@@
- lookup_commit_reference_gently(E1->hash, E2)
+ lookup_commit_reference_gently(E1, E2)
@@
expression E1;
@@
- lookup_commit_reference(E1.hash)
+ lookup_commit_reference(&E1)
@@
expression E1;
@@
- lookup_commit_reference(E1->hash)
+ lookup_commit_reference(E1)
@@
expression E1;
@@
- lookup_commit(E1.hash)
+ lookup_commit(&E1)
@@
expression E1;
@@
- lookup_commit(E1->hash)
+ lookup_commit(E1)
@@
expression E1, E2;
@@
- lookup_commit_or_die(E1.hash, E2)
+ lookup_commit_or_die(&E1, E2)
@@
expression E1, E2;
@@
- lookup_commit_or_die(E1->hash, E2)
+ lookup_commit_or_die(E1, E2)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-06 22:10:10 +00:00
|
|
|
current_head = lookup_commit_or_die(&oid, "HEAD");
|
2023-03-28 13:58:48 +00:00
|
|
|
if (repo_parse_commit(the_repository, current_head))
|
2011-08-19 18:58:18 +00:00
|
|
|
die(_("could not parse HEAD commit"));
|
|
|
|
}
|
2016-05-05 09:50:02 +00:00
|
|
|
verbose = -1; /* unspecified */
|
2012-05-07 19:18:26 +00:00
|
|
|
argc = parse_and_validate_options(argc, argv, builtin_commit_options,
|
|
|
|
builtin_commit_usage,
|
2011-08-19 18:58:18 +00:00
|
|
|
prefix, current_head, &s);
|
2016-05-05 09:50:02 +00:00
|
|
|
if (verbose == -1)
|
|
|
|
verbose = (config_commit_verbose < 0) ? 0 : config_commit_verbose;
|
|
|
|
|
2011-08-18 05:05:35 +00:00
|
|
|
if (dry_run)
|
2020-09-30 12:28:18 +00:00
|
|
|
return dry_run_commit(argv, prefix, current_head, &s);
|
|
|
|
index_file = prepare_index(argv, prefix, current_head, 0);
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2008-02-05 10:01:46 +00:00
|
|
|
/* Set up everything for writing the commit object. This includes
|
|
|
|
running hooks, writing the trees, and interacting with the user. */
|
2011-08-19 18:58:18 +00:00
|
|
|
if (!prepare_to_commit(index_file, prefix,
|
|
|
|
current_head, &s, &author_ident)) {
|
commit: fix "author_ident" leak
Since 4c28e4ada03 (commit: die before asking to edit the log
message, 2010-12-20), we have been "leaking" the "author_ident" when
prepare_to_commit() fails. Instead of returning from right there,
introduce an exit status variable and jump to the clean-up label
at the end.
Instead of explicitly releasing the resource with strbuf_release(),
mark the variable with UNLEAK() at the end, together with two other
variables that are already marked as such. If this were in a
utility function that is called number of times, but these are
different, we should explicitly release resources that grow
proportionally to the size of the problem being solved, but
cmd_commit() is like main() and there is no point in spending extra
cycles to release individual pieces of resource at the end, just
before process exit will clean everything for us for free anyway.
This fixes a leak demonstrated by e.g. "t3505-cherry-pick-empty.sh",
but unfortunately we cannot mark it or other affected tests as passing
now with "TEST_PASSES_SANITIZE_LEAK=true" as we'll need to fix many
other memory leaks before doing so.
Incidentally there are two tests that always passes the leak checker
with or without this change. Mark them as such.
This is based on an earlier patch by Ævar, but takes a different
approach that is more maintainable.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-12 22:51:07 +00:00
|
|
|
ret = 1;
|
2007-11-18 09:52:55 +00:00
|
|
|
rollback_index_files();
|
commit: fix "author_ident" leak
Since 4c28e4ada03 (commit: die before asking to edit the log
message, 2010-12-20), we have been "leaking" the "author_ident" when
prepare_to_commit() fails. Instead of returning from right there,
introduce an exit status variable and jump to the clean-up label
at the end.
Instead of explicitly releasing the resource with strbuf_release(),
mark the variable with UNLEAK() at the end, together with two other
variables that are already marked as such. If this were in a
utility function that is called number of times, but these are
different, we should explicitly release resources that grow
proportionally to the size of the problem being solved, but
cmd_commit() is like main() and there is no point in spending extra
cycles to release individual pieces of resource at the end, just
before process exit will clean everything for us for free anyway.
This fixes a leak demonstrated by e.g. "t3505-cherry-pick-empty.sh",
but unfortunately we cannot mark it or other affected tests as passing
now with "TEST_PASSES_SANITIZE_LEAK=true" as we'll need to fix many
other memory leaks before doing so.
Incidentally there are two tests that always passes the leak checker
with or without this change. Mark them as such.
This is based on an earlier patch by Ævar, but takes a different
approach that is more maintainable.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-12 22:51:07 +00:00
|
|
|
goto cleanup;
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Determine parents */
|
2010-06-12 16:05:12 +00:00
|
|
|
reflog_msg = getenv("GIT_REFLOG_ACTION");
|
2011-08-19 18:58:18 +00:00
|
|
|
if (!current_head) {
|
2010-06-12 16:05:12 +00:00
|
|
|
if (!reflog_msg)
|
|
|
|
reflog_msg = "commit (initial)";
|
2007-11-08 16:59:00 +00:00
|
|
|
} else if (amend) {
|
2010-06-12 16:05:12 +00:00
|
|
|
if (!reflog_msg)
|
|
|
|
reflog_msg = "commit (amend)";
|
2016-10-29 12:55:36 +00:00
|
|
|
parents = copy_commit_list(current_head->parents);
|
2011-02-20 04:12:29 +00:00
|
|
|
} else if (whence == FROM_MERGE) {
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf m = STRBUF_INIT;
|
2007-11-08 16:59:00 +00:00
|
|
|
FILE *fp;
|
2014-01-30 15:15:56 +00:00
|
|
|
int allow_fast_forward = 1;
|
2016-10-29 12:55:36 +00:00
|
|
|
struct commit_list **pptr = &parents;
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2010-06-12 16:05:12 +00:00
|
|
|
if (!reflog_msg)
|
|
|
|
reflog_msg = "commit (merge)";
|
2016-10-29 12:55:36 +00:00
|
|
|
pptr = commit_list_append(current_head, pptr);
|
2018-05-17 22:51:51 +00:00
|
|
|
fp = xfopen(git_path_merge_head(the_repository), "r");
|
2016-01-13 23:31:17 +00:00
|
|
|
while (strbuf_getline_lf(&m, fp) != EOF) {
|
2011-11-08 00:21:32 +00:00
|
|
|
struct commit *parent;
|
|
|
|
|
|
|
|
parent = get_merge_parent(m.buf);
|
|
|
|
if (!parent)
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("Corrupt MERGE_HEAD file (%s)"), m.buf);
|
2016-10-29 12:55:36 +00:00
|
|
|
pptr = commit_list_append(parent, pptr);
|
2008-01-16 00:12:33 +00:00
|
|
|
}
|
2007-11-08 16:59:00 +00:00
|
|
|
fclose(fp);
|
|
|
|
strbuf_release(&m);
|
2018-05-17 22:51:51 +00:00
|
|
|
if (!stat(git_path_merge_mode(the_repository), &statbuf)) {
|
|
|
|
if (strbuf_read_file(&sb, git_path_merge_mode(the_repository), 0) < 0)
|
2011-02-22 23:41:44 +00:00
|
|
|
die_errno(_("could not read MERGE_MODE"));
|
builtin-commit: use reduce_heads() only when appropriate
Since commit 6bb6b034 (builtin-commit: use commit_tree(), 2008-09-10),
builtin-commit performs a reduce_heads() unconditionally. However,
it's not always needed, and in some cases even harmful.
reduce_heads() is not needed for the initial commit or for an
"ordinary" commit, because they don't have any or have only one
parent, respectively.
reduce_heads() must be avoided when 'git commit' is run after a 'git
merge --no-ff --no-commit', otherwise it will turn the
non-fast-forward merge into fast-forward. For the same reason,
reduce_heads() must be avoided when amending such a merge commit.
To resolve this issue, 'git merge' will write info about whether
fast-forward is allowed or not to $GIT_DIR/MERGE_MODE. Based on this
info, 'git commit' will only perform reduce_heads() when it's
committing a merge and fast-forward is enabled.
Also add test cases to ensure that non-fast-forward merges are
committed and amended properly.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-03 12:04:47 +00:00
|
|
|
if (!strcmp(sb.buf, "no-ff"))
|
|
|
|
allow_fast_forward = 0;
|
|
|
|
}
|
|
|
|
if (allow_fast_forward)
|
2017-11-07 20:39:45 +00:00
|
|
|
reduce_heads_replace(&parents);
|
2007-11-08 16:59:00 +00:00
|
|
|
} else {
|
2010-06-12 16:05:12 +00:00
|
|
|
if (!reflog_msg)
|
2019-12-06 16:06:10 +00:00
|
|
|
reflog_msg = is_from_cherry_pick(whence)
|
2011-02-20 04:12:29 +00:00
|
|
|
? "commit (cherry-pick)"
|
2019-12-06 16:06:12 +00:00
|
|
|
: is_from_rebase(whence)
|
|
|
|
? "commit (rebase)"
|
2011-02-20 04:12:29 +00:00
|
|
|
: "commit";
|
2016-10-29 12:55:36 +00:00
|
|
|
commit_list_insert(current_head, &parents);
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|
|
|
|
|
2008-02-05 10:01:46 +00:00
|
|
|
/* Finally, get the commit message */
|
builtin-commit: use reduce_heads() only when appropriate
Since commit 6bb6b034 (builtin-commit: use commit_tree(), 2008-09-10),
builtin-commit performs a reduce_heads() unconditionally. However,
it's not always needed, and in some cases even harmful.
reduce_heads() is not needed for the initial commit or for an
"ordinary" commit, because they don't have any or have only one
parent, respectively.
reduce_heads() must be avoided when 'git commit' is run after a 'git
merge --no-ff --no-commit', otherwise it will turn the
non-fast-forward merge into fast-forward. For the same reason,
reduce_heads() must be avoided when amending such a merge commit.
To resolve this issue, 'git merge' will write info about whether
fast-forward is allowed or not to $GIT_DIR/MERGE_MODE. Based on this
info, 'git commit' will only perform reduce_heads() when it's
committing a merge and fast-forward is enabled.
Also add test cases to ensure that non-fast-forward merges are
committed and amended properly.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-03 12:04:47 +00:00
|
|
|
strbuf_reset(&sb);
|
2016-05-24 19:19:50 +00:00
|
|
|
if (strbuf_read_file(&sb, git_path_commit_editmsg(), 0) < 0) {
|
2009-06-27 15:58:47 +00:00
|
|
|
int saved_errno = errno;
|
2007-12-09 07:23:20 +00:00
|
|
|
rollback_index_files();
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("could not read commit message: %s"), strerror(saved_errno));
|
2007-12-09 07:23:20 +00:00
|
|
|
}
|
2007-11-22 02:54:49 +00:00
|
|
|
|
2019-04-17 10:23:25 +00:00
|
|
|
cleanup_message(&sb, cleanup_mode, verbose);
|
2017-07-17 15:36:15 +00:00
|
|
|
|
2017-11-10 11:09:42 +00:00
|
|
|
if (message_is_empty(&sb, cleanup_mode) && !allow_empty_message) {
|
2012-03-30 19:14:33 +00:00
|
|
|
rollback_index_files();
|
2017-07-17 15:36:15 +00:00
|
|
|
fprintf(stderr, _("Aborting commit due to empty commit message.\n"));
|
2012-03-30 19:14:33 +00:00
|
|
|
exit(1);
|
|
|
|
}
|
2017-11-10 11:09:42 +00:00
|
|
|
if (template_untouched(&sb, template_file, cleanup_mode) && !allow_empty_message) {
|
2007-11-18 09:52:55 +00:00
|
|
|
rollback_index_files();
|
2017-07-17 15:36:15 +00:00
|
|
|
fprintf(stderr, _("Aborting commit; you did not edit the message.\n"));
|
2008-07-31 07:36:09 +00:00
|
|
|
exit(1);
|
2007-11-18 09:52:55 +00:00
|
|
|
}
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2021-03-15 07:54:32 +00:00
|
|
|
if (fixup_message && starts_with(sb.buf, "amend! ") &&
|
|
|
|
!allow_empty_message) {
|
|
|
|
struct strbuf body = STRBUF_INIT;
|
|
|
|
size_t len = commit_subject_length(sb.buf);
|
|
|
|
strbuf_addstr(&body, sb.buf + len);
|
|
|
|
if (message_is_empty(&body, cleanup_mode)) {
|
|
|
|
rollback_index_files();
|
|
|
|
fprintf(stderr, _("Aborting commit due to empty commit message body.\n"));
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
strbuf_release(&body);
|
|
|
|
}
|
|
|
|
|
2011-12-20 21:20:56 +00:00
|
|
|
if (amend) {
|
2020-02-22 20:17:42 +00:00
|
|
|
const char *exclude_gpgsig[3] = { "gpgsig", "gpgsig-sha256", NULL };
|
2012-01-05 18:54:14 +00:00
|
|
|
extra = read_commit_extra_headers(current_head, exclude_gpgsig);
|
2011-12-20 21:20:56 +00:00
|
|
|
} else {
|
|
|
|
struct commit_extra_header **tail = &extra;
|
|
|
|
append_merge_tag_headers(parents, &tail);
|
|
|
|
}
|
2011-11-08 23:38:07 +00:00
|
|
|
|
2022-11-19 13:07:34 +00:00
|
|
|
if (commit_tree_extended(sb.buf, sb.len, &the_index.cache_tree->oid,
|
2020-08-17 17:40:01 +00:00
|
|
|
parents, &oid, author_ident.buf, NULL,
|
|
|
|
sign_commit, extra)) {
|
2007-11-18 09:52:55 +00:00
|
|
|
rollback_index_files();
|
2011-02-22 23:41:44 +00:00
|
|
|
die(_("failed to write commit object"));
|
2007-11-18 09:52:55 +00:00
|
|
|
}
|
2011-11-08 23:38:07 +00:00
|
|
|
free_commit_extra_headers(extra);
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2017-11-17 11:34:47 +00:00
|
|
|
if (update_head_with_reflog(current_head, &oid, reflog_msg, &sb,
|
|
|
|
&err)) {
|
2007-11-18 09:52:55 +00:00
|
|
|
rollback_index_files();
|
2014-04-16 22:34:19 +00:00
|
|
|
die("%s", err.buf);
|
2007-11-18 09:52:55 +00:00
|
|
|
}
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2019-07-09 22:25:44 +00:00
|
|
|
sequencer_post_commit_cleanup(the_repository, 0);
|
2018-05-17 22:51:51 +00:00
|
|
|
unlink(git_path_merge_head(the_repository));
|
|
|
|
unlink(git_path_merge_msg(the_repository));
|
|
|
|
unlink(git_path_merge_mode(the_repository));
|
|
|
|
unlink(git_path_squash_msg(the_repository));
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2008-01-23 17:21:22 +00:00
|
|
|
if (commit_index_files())
|
2018-07-21 07:49:19 +00:00
|
|
|
die(_("repository has been updated, but unable to write\n"
|
|
|
|
"new_index file. Check that disk is not full and quota is\n"
|
2019-04-25 09:45:58 +00:00
|
|
|
"not exceeded, and then \"git restore --staged :/\" to recover."));
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2020-04-16 20:14:03 +00:00
|
|
|
git_test_write_commit_graph_or_die();
|
2018-08-29 12:49:04 +00:00
|
|
|
|
2018-09-21 15:57:32 +00:00
|
|
|
repo_rerere(the_repository, 0);
|
2020-09-17 18:11:44 +00:00
|
|
|
run_auto_maintenance(quiet);
|
hooks: fix an obscure TOCTOU "did we just run a hook?" race
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in
680ee550d72 (commit: skip discarding the index if there is no
pre-commit hook, 2017-08-14).
This obscure race condition can occur if we e.g. ran the "pre-commit"
hook and it modified the index, but hook_exists() returns false later
on (e.g., because the hook itself went away, the directory became
unreadable, etc.). Then we won't call discard_cache() when we should
have.
The race condition itself probably doesn't matter, and users would
have been unlikely to run into it in practice. This problem has been
noted on-list when 680ee550d72 was discussed[1], but had not been
fixed.
This change is mainly intended to improve the readability of the code
involved, and to make reasoning about it more straightforward. It
wasn't as obvious what we were trying to do here, but by having an
"invoked_hook" it's clearer that e.g. our discard_cache() is happening
because of the earlier hook execution.
Let's also change this for the push-to-checkout hook. Now instead of
checking if the hook exists and either doing a push to checkout or a
push to deploy we'll always attempt a push to checkout. If the hook
doesn't exist we'll fall back on push to deploy. The same behavior as
before, without the TOCTOU race. See 0855331941b (receive-pack:
support push-to-checkout hook, 2014-12-01) for the introduction of the
previous behavior.
This leaves uses of hook_exists() in two places that matter. The
"reference-transaction" check in refs.c, see 67541597670 (refs:
implement reference transaction hook, 2020-06-19), and the
"prepare-commit-msg" hook, see 66618a50f9c (sequencer: run
'prepare-commit-msg' hook, 2018-01-24).
In both of those cases we're saving ourselves CPU time by not
preparing data for the hook that we'll then do nothing with if we
don't have the hook. So using this "invoked_hook" pattern doesn't make
sense in those cases.
The "reference-transaction" and "prepare-commit-msg" hook also aren't
racy. In those cases we'll skip the hook runs if we race with a new
hook being added, whereas in the TOCTOU races being fixed here we were
incorrectly skipping the required post-hook logic.
1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:33:46 +00:00
|
|
|
run_commit_hook(use_editor, get_index_file(), NULL, "post-commit",
|
|
|
|
NULL);
|
2010-03-12 17:04:28 +00:00
|
|
|
if (amend && !no_post_rewrite) {
|
2019-01-12 02:13:23 +00:00
|
|
|
commit_post_rewrite(the_repository, current_head, &oid);
|
2010-03-12 17:04:28 +00:00
|
|
|
}
|
2017-11-24 11:07:54 +00:00
|
|
|
if (!quiet) {
|
|
|
|
unsigned int flags = 0;
|
|
|
|
|
|
|
|
if (!current_head)
|
|
|
|
flags |= SUMMARY_INITIAL_COMMIT;
|
|
|
|
if (author_date_is_interesting())
|
|
|
|
flags |= SUMMARY_SHOW_AUTHOR_DATE;
|
2018-11-10 05:48:56 +00:00
|
|
|
print_commit_summary(the_repository, prefix,
|
|
|
|
&oid, flags);
|
2010-03-12 17:04:28 +00:00
|
|
|
}
|
2007-11-08 16:59:00 +00:00
|
|
|
|
2020-04-07 14:28:07 +00:00
|
|
|
apply_autostash(git_path_merge_autostash(the_repository));
|
|
|
|
|
commit: fix "author_ident" leak
Since 4c28e4ada03 (commit: die before asking to edit the log
message, 2010-12-20), we have been "leaking" the "author_ident" when
prepare_to_commit() fails. Instead of returning from right there,
introduce an exit status variable and jump to the clean-up label
at the end.
Instead of explicitly releasing the resource with strbuf_release(),
mark the variable with UNLEAK() at the end, together with two other
variables that are already marked as such. If this were in a
utility function that is called number of times, but these are
different, we should explicitly release resources that grow
proportionally to the size of the problem being solved, but
cmd_commit() is like main() and there is no point in spending extra
cycles to release individual pieces of resource at the end, just
before process exit will clean everything for us for free anyway.
This fixes a leak demonstrated by e.g. "t3505-cherry-pick-empty.sh",
but unfortunately we cannot mark it or other affected tests as passing
now with "TEST_PASSES_SANITIZE_LEAK=true" as we'll need to fix many
other memory leaks before doing so.
Incidentally there are two tests that always passes the leak checker
with or without this change. Mark them as such.
This is based on an earlier patch by Ævar, but takes a different
approach that is more maintainable.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-12 22:51:07 +00:00
|
|
|
cleanup:
|
built-ins: use free() not UNLEAK() if trivial, rm dead code
For a lot of uses of UNLEAK() it would be quite tricky to release the
memory involved, or we're missing the relevant *_(release|clear)()
functions. But in these cases we have them already, and can just
invoke them on the variable(s) involved, instead of UNLEAK().
For "builtin/worktree.c" the UNLEAK() was also added in [1], but the
struct member it's unleaking was removed in [2]. The only non-"int"
member of that structure is "const char *keep_locked", which comes to
us via "argv" or a string literal[3].
We have good visibility via the compiler and
tooling (e.g. SANITIZE=address) on bad free()-ing, but none on
UNLEAK() we don't need anymore. So let's prefer releasing the memory
when it's easy.
For "bugreport", "worktree" and "config" we need to start using a "ret
= ..." return pattern. For "builtin/bugreport.c" these UNLEAK() were
added in [4], and for "builtin/config.c" in [1].
For "config" the code seen here was the only user of the "value"
variable. For "ACTION_{RENAME,REMOVE}_SECTION" we need to be sure to
return the right exit code in the cases where we were relying on
falling through to the top-level.
I think there's still a use-case for UNLEAK(), but hat it's changed
since then. Using it so that "we can see the real leaks" is
counter-productive in these cases.
It's more useful to have UNLEAK() be a marker of the remaining odd
cases where it's hard to free() the memory for whatever reason. With
this change less than 20 of them remain in-tree.
1. 0e5bba53af7 (add UNLEAK annotation for reducing leak false
positives, 2017-09-08)
2. d861d34a6ed (worktree: remove extra members from struct add_opts,
2018-04-24)
3. 0db4961c49b (worktree: teach `add` to accept --reason <string> with
--lock, 2021-07-15)
4. 0e5bba53af7 and 00d8c311050 (commit: fix "author_ident" leak,
2022-05-12).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-11-08 18:17:51 +00:00
|
|
|
strbuf_release(&author_ident);
|
|
|
|
strbuf_release(&err);
|
|
|
|
strbuf_release(&sb);
|
commit: fix "author_ident" leak
Since 4c28e4ada03 (commit: die before asking to edit the log
message, 2010-12-20), we have been "leaking" the "author_ident" when
prepare_to_commit() fails. Instead of returning from right there,
introduce an exit status variable and jump to the clean-up label
at the end.
Instead of explicitly releasing the resource with strbuf_release(),
mark the variable with UNLEAK() at the end, together with two other
variables that are already marked as such. If this were in a
utility function that is called number of times, but these are
different, we should explicitly release resources that grow
proportionally to the size of the problem being solved, but
cmd_commit() is like main() and there is no point in spending extra
cycles to release individual pieces of resource at the end, just
before process exit will clean everything for us for free anyway.
This fixes a leak demonstrated by e.g. "t3505-cherry-pick-empty.sh",
but unfortunately we cannot mark it or other affected tests as passing
now with "TEST_PASSES_SANITIZE_LEAK=true" as we'll need to fix many
other memory leaks before doing so.
Incidentally there are two tests that always passes the leak checker
with or without this change. Mark them as such.
This is based on an earlier patch by Ævar, but takes a different
approach that is more maintainable.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-12 22:51:07 +00:00
|
|
|
return ret;
|
2007-11-08 16:59:00 +00:00
|
|
|
}
|