2014-10-13 18:16:29 +00:00
|
|
|
/*
|
|
|
|
|
* Builtin "git interpret-trailers"
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2013, 2014 Christian Couder <chriscool@tuxfamily.org>
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "builtin.h"
|
2023-03-21 06:25:54 +00:00
|
|
|
#include "gettext.h"
|
2014-10-13 18:16:29 +00:00
|
|
|
#include "parse-options.h"
|
|
|
|
|
#include "string-list.h"
|
|
|
|
|
#include "trailer.h"
|
2019-06-19 03:37:28 +00:00
|
|
|
#include "config.h"
|
2014-10-13 18:16:29 +00:00
|
|
|
|
|
|
|
|
static const char * const git_interpret_trailers_usage[] = {
|
2022-10-13 15:39:02 +00:00
|
|
|
N_("git interpret-trailers [--in-place] [--trim-empty]\n"
|
|
|
|
|
" [(--trailer <token>[(=|:)<value>])...]\n"
|
2022-10-13 15:39:18 +00:00
|
|
|
" [--parse] [<file>...]"),
|
2014-10-13 18:16:29 +00:00
|
|
|
NULL
|
|
|
|
|
};
|
|
|
|
|
|
2017-08-01 09:03:32 +00:00
|
|
|
static enum trailer_where where;
|
|
|
|
|
static enum trailer_if_exists if_exists;
|
|
|
|
|
static enum trailer_if_missing if_missing;
|
|
|
|
|
|
|
|
|
|
static int option_parse_where(const struct option *opt,
|
|
|
|
|
const char *arg, int unset)
|
|
|
|
|
{
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-08-31 21:21:07 +00:00
|
|
|
return trailer_set_where(opt->value, arg);
|
2017-08-01 09:03:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int option_parse_if_exists(const struct option *opt,
|
|
|
|
|
const char *arg, int unset)
|
|
|
|
|
{
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-08-31 21:21:07 +00:00
|
|
|
return trailer_set_if_exists(opt->value, arg);
|
2017-08-01 09:03:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int option_parse_if_missing(const struct option *opt,
|
|
|
|
|
const char *arg, int unset)
|
|
|
|
|
{
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-08-31 21:21:07 +00:00
|
|
|
return trailer_set_if_missing(opt->value, arg);
|
2017-08-01 09:03:32 +00:00
|
|
|
}
|
|
|
|
|
|
2017-08-01 09:03:31 +00:00
|
|
|
static void new_trailers_clear(struct list_head *trailers)
|
|
|
|
|
{
|
|
|
|
|
struct list_head *pos, *tmp;
|
|
|
|
|
struct new_trailer_item *item;
|
|
|
|
|
|
|
|
|
|
list_for_each_safe(pos, tmp, trailers) {
|
|
|
|
|
item = list_entry(pos, struct new_trailer_item, list);
|
|
|
|
|
list_del(pos);
|
|
|
|
|
free(item);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int option_parse_trailer(const struct option *opt,
|
|
|
|
|
const char *arg, int unset)
|
|
|
|
|
{
|
|
|
|
|
struct list_head *trailers = opt->value;
|
|
|
|
|
struct new_trailer_item *item;
|
|
|
|
|
|
|
|
|
|
if (unset) {
|
|
|
|
|
new_trailers_clear(trailers);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!arg)
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
item = xmalloc(sizeof(*item));
|
|
|
|
|
item->text = arg;
|
2017-08-01 09:03:32 +00:00
|
|
|
item->where = where;
|
|
|
|
|
item->if_exists = if_exists;
|
|
|
|
|
item->if_missing = if_missing;
|
2017-08-01 09:03:31 +00:00
|
|
|
list_add_tail(&item->list, trailers);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-15 10:23:34 +00:00
|
|
|
static int parse_opt_parse(const struct option *opt, const char *arg,
|
|
|
|
|
int unset)
|
|
|
|
|
{
|
|
|
|
|
struct process_trailer_options *v = opt->value;
|
|
|
|
|
v->only_trailers = 1;
|
|
|
|
|
v->only_input = 1;
|
|
|
|
|
v->unfold = 1;
|
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);
|
|
|
|
|
BUG_ON_OPT_ARG(arg);
|
2017-08-15 10:23:34 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-13 18:16:29 +00:00
|
|
|
int cmd_interpret_trailers(int argc, const char **argv, const char *prefix)
|
|
|
|
|
{
|
2017-08-10 18:03:58 +00:00
|
|
|
struct process_trailer_options opts = PROCESS_TRAILER_OPTIONS_INIT;
|
2017-08-01 09:03:31 +00:00
|
|
|
LIST_HEAD(trailers);
|
2014-10-13 18:16:29 +00:00
|
|
|
|
|
|
|
|
struct option options[] = {
|
2017-08-10 18:03:58 +00:00
|
|
|
OPT_BOOL(0, "in-place", &opts.in_place, N_("edit files in place")),
|
|
|
|
|
OPT_BOOL(0, "trim-empty", &opts.trim_empty, N_("trim empty trailers")),
|
2017-08-01 09:03:31 +00:00
|
|
|
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-08-31 21:21:07 +00:00
|
|
|
OPT_CALLBACK(0, "where", &where, N_("action"),
|
2017-08-01 09:03:32 +00:00
|
|
|
N_("where to place the new trailer"), option_parse_where),
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-08-31 21:21:07 +00:00
|
|
|
OPT_CALLBACK(0, "if-exists", &if_exists, N_("action"),
|
2017-08-01 09:03:32 +00:00
|
|
|
N_("action if trailer already exists"), option_parse_if_exists),
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-08-31 21:21:07 +00:00
|
|
|
OPT_CALLBACK(0, "if-missing", &if_missing, N_("action"),
|
2017-08-01 09:03:32 +00:00
|
|
|
N_("action if trailer is missing"), option_parse_if_missing),
|
|
|
|
|
|
2017-08-15 10:23:21 +00:00
|
|
|
OPT_BOOL(0, "only-trailers", &opts.only_trailers, N_("output only the trailers")),
|
2017-08-15 10:23:25 +00:00
|
|
|
OPT_BOOL(0, "only-input", &opts.only_input, N_("do not apply config rules")),
|
2017-08-15 10:23:29 +00:00
|
|
|
OPT_BOOL(0, "unfold", &opts.unfold, N_("join whitespace-continued 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, "parse", &opts, NULL, N_("set parsing options"),
|
|
|
|
|
PARSE_OPT_NOARG | PARSE_OPT_NONEG, parse_opt_parse),
|
2018-08-23 00:49:56 +00:00
|
|
|
OPT_BOOL(0, "no-divider", &opts.no_divider, N_("do not treat --- specially")),
|
2017-08-01 09:03:31 +00:00
|
|
|
OPT_CALLBACK(0, "trailer", &trailers, N_("trailer"),
|
|
|
|
|
N_("trailer(s) to add"), option_parse_trailer),
|
2014-10-13 18:16:29 +00:00
|
|
|
OPT_END()
|
|
|
|
|
};
|
|
|
|
|
|
2019-06-19 03:37:28 +00:00
|
|
|
git_config(git_default_config, NULL);
|
|
|
|
|
|
2014-10-13 18:16:29 +00:00
|
|
|
argc = parse_options(argc, argv, prefix, options,
|
|
|
|
|
git_interpret_trailers_usage, 0);
|
|
|
|
|
|
2017-08-27 05:55:04 +00:00
|
|
|
if (opts.only_input && !list_empty(&trailers))
|
2017-08-15 10:23:25 +00:00
|
|
|
usage_msg_opt(
|
|
|
|
|
_("--trailer with --only-input does not make sense"),
|
|
|
|
|
git_interpret_trailers_usage,
|
|
|
|
|
options);
|
|
|
|
|
|
2014-10-13 18:16:29 +00:00
|
|
|
if (argc) {
|
|
|
|
|
int i;
|
|
|
|
|
for (i = 0; i < argc; i++)
|
2017-08-10 18:03:58 +00:00
|
|
|
process_trailers(argv[i], &opts, &trailers);
|
2016-01-14 16:57:55 +00:00
|
|
|
} else {
|
2017-08-10 18:03:58 +00:00
|
|
|
if (opts.in_place)
|
2016-01-14 16:57:55 +00:00
|
|
|
die(_("no input file given for in-place editing"));
|
2017-08-10 18:03:58 +00:00
|
|
|
process_trailers(NULL, &opts, &trailers);
|
2016-01-14 16:57:55 +00:00
|
|
|
}
|
2014-10-13 18:16:29 +00:00
|
|
|
|
2017-08-01 09:03:31 +00:00
|
|
|
new_trailers_clear(&trailers);
|
2014-10-13 18:16:29 +00:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|