2007-07-20 01:42:28 +02:00
|
|
|
/*
|
|
|
|
* Builtin "git tag"
|
|
|
|
*
|
|
|
|
* Copyright (c) 2007 Kristian Høgsberg <krh@redhat.com>,
|
|
|
|
* Carlos Rica <jasampler@gmail.com>
|
|
|
|
* Based on git-tag.sh and mktag.c by Linus Torvalds.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "cache.h"
|
2017-06-14 20:07:36 +02:00
|
|
|
#include "config.h"
|
2007-07-20 01:42:28 +02:00
|
|
|
#include "builtin.h"
|
2023-03-21 07:25:57 +01:00
|
|
|
#include "environment.h"
|
2023-03-21 07:25:54 +01:00
|
|
|
#include "gettext.h"
|
2023-02-24 01:09:27 +01:00
|
|
|
#include "hex.h"
|
2007-07-20 01:42:28 +02:00
|
|
|
#include "refs.h"
|
2018-05-16 01:42:15 +02:00
|
|
|
#include "object-store.h"
|
2007-07-20 01:42:28 +02:00
|
|
|
#include "tag.h"
|
|
|
|
#include "run-command.h"
|
2007-11-09 14:42:56 +01:00
|
|
|
#include "parse-options.h"
|
2011-06-11 21:04:08 +02:00
|
|
|
#include "diff.h"
|
|
|
|
#include "revision.h"
|
2011-09-08 06:19:47 +02:00
|
|
|
#include "gpg-interface.h"
|
2020-03-30 16:03:46 +02:00
|
|
|
#include "oid-array.h"
|
2012-04-13 12:54:41 +02:00
|
|
|
#include "column.h"
|
2015-09-10 17:48:27 +02:00
|
|
|
#include "ref-filter.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 09:14:02 +01:00
|
|
|
#include "date.h"
|
2023-03-21 07:26:07 +01:00
|
|
|
#include "write-or-die.h"
|
2007-11-09 14:42:56 +01:00
|
|
|
|
|
|
|
static const char * const git_tag_usage[] = {
|
2022-10-13 17:39:13 +02:00
|
|
|
N_("git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]\n"
|
|
|
|
" <tagname> [<commit> | <object>]"),
|
2012-08-20 14:32:47 +02:00
|
|
|
N_("git tag -d <tagname>..."),
|
2022-10-13 17:39:13 +02:00
|
|
|
N_("git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]\n"
|
|
|
|
" [--points-at <object>] [--column[=<options>] | --no-column]\n"
|
|
|
|
" [--create-reflog] [--sort=<key>] [--format=<format>]\n"
|
|
|
|
" [--merged <commit>] [--no-merged <commit>] [<pattern>...]"),
|
2017-01-18 00:37:21 +01:00
|
|
|
N_("git tag -v [--format=<format>] <tagname>..."),
|
2007-11-09 14:42:56 +01:00
|
|
|
NULL
|
|
|
|
};
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2012-04-13 12:54:41 +02:00
|
|
|
static unsigned int colopts;
|
2016-03-22 21:41:26 +01:00
|
|
|
static int force_sign_annotate;
|
2019-06-05 23:33:21 +02:00
|
|
|
static int config_sign_tag = -1; /* unspecified */
|
2023-04-07 19:53:16 +02:00
|
|
|
static int omit_empty = 0;
|
2012-02-09 00:03:43 +01:00
|
|
|
|
2017-07-13 17:01:18 +02:00
|
|
|
static int list_tags(struct ref_filter *filter, struct ref_sorting *sorting,
|
|
|
|
struct ref_format *format)
|
2012-02-06 09:13:12 +01:00
|
|
|
{
|
2015-09-10 17:48:27 +02:00
|
|
|
struct ref_array array;
|
2021-04-20 18:52:11 +02:00
|
|
|
struct strbuf output = STRBUF_INIT;
|
|
|
|
struct strbuf err = STRBUF_INIT;
|
2015-09-11 17:06:46 +02:00
|
|
|
char *to_free = NULL;
|
2012-02-06 09:13:12 +01:00
|
|
|
int i;
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2015-09-10 17:48:27 +02:00
|
|
|
memset(&array, 0, sizeof(array));
|
2009-01-26 15:13:25 +01:00
|
|
|
|
2015-09-10 17:48:27 +02:00
|
|
|
if (filter->lines == -1)
|
|
|
|
filter->lines = 0;
|
2012-02-09 00:03:43 +01:00
|
|
|
|
2017-07-13 17:01:18 +02:00
|
|
|
if (!format->format) {
|
2015-09-11 17:06:46 +02:00
|
|
|
if (filter->lines) {
|
|
|
|
to_free = xstrfmt("%s %%(contents:lines=%d)",
|
2017-01-10 09:49:46 +01:00
|
|
|
"%(align:15)%(refname:lstrip=2)%(end)",
|
2015-09-11 17:06:46 +02:00
|
|
|
filter->lines);
|
2017-07-13 17:01:18 +02:00
|
|
|
format->format = to_free;
|
2015-09-11 17:06:46 +02:00
|
|
|
} else
|
2017-07-13 17:01:18 +02:00
|
|
|
format->format = "%(refname:lstrip=2)";
|
2007-07-20 01:42:28 +02:00
|
|
|
}
|
|
|
|
|
2017-07-13 16:56:10 +02:00
|
|
|
if (verify_ref_format(format))
|
|
|
|
die(_("unable to parse format string"));
|
2015-10-18 12:25:04 +02:00
|
|
|
filter->with_commit_tag_algo = 1;
|
2015-09-11 17:06:16 +02:00
|
|
|
filter_refs(&array, filter, FILTER_REFS_TAGS);
|
for-each-ref: add ahead-behind format atom
The previous change implemented the ahead_behind() method, including an
algorithm to compute the ahead/behind values for a number of commit tips
relative to a number of commit bases. Now, integrate that algorithm as
part of 'git for-each-ref' hidden behind a new format atom,
ahead-behind. This naturally extends to 'git branch' and 'git tag'
builtins, as well.
This format allows specifying multiple bases, if so desired, and all
matching references are compared against all of those bases. For this
reason, failing to read a reference provided from these atoms results in
an error.
In order to translate the ahead_behind() method information to the
format output code in ref-filter.c, we must populate arrays of
ahead_behind_count structs. In struct ref_array, we store the full array
that will be passed to ahead_behind(). In struct ref_array_item, we
store an array of pointers that point to the relvant items within the
full array. In this way, we can pull all relevant ahead/behind values
directly when formatting output for a specific item. It also ensures the
lifetime of the ahead_behind_count structs matches the time that the
array is being used.
Add specific tests of the ahead/behind counts in t6600-test-reach.sh, as
it has an interesting repository shape. In particular, its merging
strategy and its use of different commit-graphs would demonstrate over-
counting if the ahead_behind() method did not already account for that
possibility.
Also add tests for the specific for-each-ref, branch, and tag builtins.
In the case of 'git tag', there are intersting cases that happen when
some of the selected tips are not commits. This requires careful logic
around commits_nr in the second loop of filter_ahead_behind(). Also, the
test in t7004 is carefully located to avoid being dependent on the GPG
prereq. It also avoids using the test_commit helper, as that will add
ticks to the time and disrupt the expected timestamps in later tag
tests.
Also add performance tests in a new p1300-graph-walks.sh script. This
will be useful for more uses in the future, but for now compare the
ahead-behind counting algorithm in 'git for-each-ref' to the naive
implementation by running 'git rev-list --count' processes for each
input.
For the Git source code repository, the improvement is already obvious:
Test this tree
---------------------------------------------------------------
1500.2: ahead-behind counts: git for-each-ref 0.07(0.07+0.00)
1500.3: ahead-behind counts: git branch 0.07(0.06+0.00)
1500.4: ahead-behind counts: git tag 0.07(0.06+0.00)
1500.5: ahead-behind counts: git rev-list 1.32(1.04+0.27)
But the standard performance benchmark is the Linux kernel repository,
which demosntrates a significant improvement:
Test this tree
---------------------------------------------------------------
1500.2: ahead-behind counts: git for-each-ref 0.27(0.24+0.02)
1500.3: ahead-behind counts: git branch 0.27(0.24+0.03)
1500.4: ahead-behind counts: git tag 0.28(0.27+0.01)
1500.5: ahead-behind counts: git rev-list 4.57(4.03+0.54)
The 'git rev-list' test exists in this change as a demonstration, but it
will be removed in the next change to avoid wasting time on this
comparison.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-20 12:26:54 +01:00
|
|
|
filter_ahead_behind(the_repository, format, &array);
|
2015-09-11 17:06:16 +02:00
|
|
|
ref_array_sort(sorting, &array);
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2021-04-19 13:28:44 +02:00
|
|
|
for (i = 0; i < array.nr; i++) {
|
2021-04-20 18:52:11 +02:00
|
|
|
strbuf_reset(&output);
|
|
|
|
strbuf_reset(&err);
|
2021-04-19 13:28:44 +02:00
|
|
|
if (format_ref_array_item(array.items[i], format, &output, &err))
|
|
|
|
die("%s", err.buf);
|
|
|
|
fwrite(output.buf, 1, output.len, stdout);
|
2023-04-07 19:53:16 +02:00
|
|
|
if (output.len || !omit_empty)
|
|
|
|
putchar('\n');
|
2021-04-19 13:28:44 +02:00
|
|
|
}
|
2021-04-20 18:52:11 +02:00
|
|
|
|
|
|
|
strbuf_release(&err);
|
|
|
|
strbuf_release(&output);
|
2015-09-11 17:06:16 +02:00
|
|
|
ref_array_clear(&array);
|
|
|
|
free(to_free);
|
2014-02-27 13:56:52 +01:00
|
|
|
|
2007-07-20 01:42:28 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-07-21 14:13:12 +02:00
|
|
|
typedef int (*each_tag_name_fn)(const char *name, const char *ref,
|
2021-01-21 04:23:32 +01:00
|
|
|
const struct object_id *oid, void *cb_data);
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2017-01-18 00:37:21 +01:00
|
|
|
static int for_each_tag_name(const char **argv, each_tag_name_fn fn,
|
2021-01-21 04:23:32 +01:00
|
|
|
void *cb_data)
|
2007-07-20 01:42:28 +02:00
|
|
|
{
|
|
|
|
const char **p;
|
2017-03-28 21:46:30 +02:00
|
|
|
struct strbuf ref = STRBUF_INIT;
|
2007-07-20 01:42:28 +02:00
|
|
|
int had_error = 0;
|
2017-05-07 00:10:08 +02:00
|
|
|
struct object_id oid;
|
2007-07-20 01:42:28 +02:00
|
|
|
|
|
|
|
for (p = argv; *p; p++) {
|
2017-03-28 21:46:30 +02:00
|
|
|
strbuf_reset(&ref);
|
|
|
|
strbuf_addf(&ref, "refs/tags/%s", *p);
|
2017-10-16 00:06:56 +02:00
|
|
|
if (read_ref(ref.buf, &oid)) {
|
2011-02-23 00:42:09 +01:00
|
|
|
error(_("tag '%s' not found."), *p);
|
2007-07-20 01:42:28 +02:00
|
|
|
had_error = 1;
|
|
|
|
continue;
|
|
|
|
}
|
2017-05-07 00:10:08 +02:00
|
|
|
if (fn(*p, ref.buf, &oid, cb_data))
|
2007-07-20 01:42:28 +02:00
|
|
|
had_error = 1;
|
|
|
|
}
|
2017-03-28 21:46:30 +02:00
|
|
|
strbuf_release(&ref);
|
2007-07-20 01:42:28 +02:00
|
|
|
return had_error;
|
|
|
|
}
|
|
|
|
|
2021-01-21 04:23:32 +01:00
|
|
|
static int collect_tags(const char *name, const char *ref,
|
|
|
|
const struct object_id *oid, void *cb_data)
|
2007-07-20 01:42:28 +02:00
|
|
|
{
|
2021-01-21 04:23:32 +01:00
|
|
|
struct string_list *ref_list = cb_data;
|
|
|
|
|
|
|
|
string_list_append(ref_list, ref);
|
|
|
|
ref_list->items[ref_list->nr - 1].util = oiddup(oid);
|
2007-07-20 01:42:28 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-01-21 04:23:32 +01:00
|
|
|
static int delete_tags(const char **argv)
|
|
|
|
{
|
|
|
|
int result;
|
|
|
|
struct string_list refs_to_delete = STRING_LIST_INIT_DUP;
|
|
|
|
struct string_list_item *item;
|
|
|
|
|
|
|
|
result = for_each_tag_name(argv, collect_tags, (void *)&refs_to_delete);
|
|
|
|
if (delete_refs(NULL, &refs_to_delete, REF_NO_DEREF))
|
|
|
|
result = 1;
|
|
|
|
|
|
|
|
for_each_string_list_item(item, &refs_to_delete) {
|
|
|
|
const char *name = item->string;
|
|
|
|
struct object_id *oid = item->util;
|
|
|
|
if (!ref_exists(name))
|
|
|
|
printf(_("Deleted tag '%s' (was %s)\n"),
|
|
|
|
item->string + 10,
|
2023-03-28 15:58:46 +02:00
|
|
|
repo_find_unique_abbrev(the_repository, oid, DEFAULT_ABBREV));
|
2021-01-21 04:23:32 +01:00
|
|
|
|
|
|
|
free(oid);
|
|
|
|
}
|
|
|
|
string_list_clear(&refs_to_delete, 0);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2007-07-20 01:42:28 +02:00
|
|
|
static int verify_tag(const char *name, const char *ref,
|
2021-01-21 04:23:32 +01:00
|
|
|
const struct object_id *oid, void *cb_data)
|
2007-07-20 01:42:28 +02:00
|
|
|
{
|
2017-01-18 00:37:21 +01:00
|
|
|
int flags;
|
2021-07-26 05:26:49 +02:00
|
|
|
struct ref_format *format = cb_data;
|
2017-01-18 00:37:21 +01:00
|
|
|
flags = GPG_VERIFY_VERBOSE;
|
|
|
|
|
2017-07-13 17:01:18 +02:00
|
|
|
if (format->format)
|
2017-01-18 00:37:21 +01:00
|
|
|
flags = GPG_VERIFY_OMIT_STATUS;
|
|
|
|
|
2017-07-13 02:44:15 +02:00
|
|
|
if (gpg_verify_tag(oid, name, flags))
|
2017-01-18 00:37:21 +01:00
|
|
|
return -1;
|
|
|
|
|
2017-07-13 17:01:18 +02:00
|
|
|
if (format->format)
|
2018-04-06 20:58:32 +02:00
|
|
|
pretty_print_ref(name, oid, format);
|
2017-01-18 00:37:21 +01:00
|
|
|
|
|
|
|
return 0;
|
2007-07-20 01:42:28 +02:00
|
|
|
}
|
|
|
|
|
2007-09-10 12:35:09 +02:00
|
|
|
static int do_sign(struct strbuf *buffer)
|
2007-07-20 01:42:28 +02:00
|
|
|
{
|
2011-09-08 06:19:47 +02:00
|
|
|
return sign_buffer(buffer, buffer, get_signing_key());
|
2007-07-20 01:42:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static const char tag_template[] =
|
2013-08-30 00:03:10 +02:00
|
|
|
N_("\nWrite a message for tag:\n %s\n"
|
2013-01-16 20:18:48 +01:00
|
|
|
"Lines starting with '%c' will be ignored.\n");
|
2011-12-07 04:01:45 +01:00
|
|
|
|
|
|
|
static const char tag_template_nocleanup[] =
|
2013-08-30 00:03:10 +02:00
|
|
|
N_("\nWrite a message for tag:\n %s\n"
|
2013-01-16 20:18:48 +01:00
|
|
|
"Lines starting with '%c' will be kept; you may remove them"
|
|
|
|
" yourself if you want to.\n");
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2008-05-14 19:46:53 +02:00
|
|
|
static int git_tag_config(const char *var, const char *value, void *cb)
|
2007-07-20 01:42:28 +02:00
|
|
|
{
|
2019-06-05 23:33:21 +02:00
|
|
|
if (!strcmp(var, "tag.gpgsign")) {
|
|
|
|
config_sign_tag = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-07-16 23:48:02 +02:00
|
|
|
if (!strcmp(var, "tag.sort")) {
|
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
for-each-ref: delay parsing of --sort=<atom> options
The for-each-ref family of commands invoke parsers immediately when
it sees each --sort=<atom> option, and die before even seeing the
other options on the command line when the <atom> is unrecognised.
Instead, accumulate them in a string list, and have them parsed into
a ref_sorting structure after the command line parsing is done. As
a consequence, "git branch --sort=bogus -h" used to fail to give the
brief help, which arguably may have been a feature, now does so,
which is more consistent with how other options work.
The patch is smaller than the actual extent of the "damage" to the
codebase, thanks to the fact that the original code consistently
used OPT_REF_SORT() macro to handle command line options. We only
needed to replace the variable used for the list, and implementation
of the callback function used in the macro.
The old rule was for the users of the API to:
- Declare ref_sorting and ref_sorting_tail variables;
- OPT_REF_SORT() macro will instantiate ref_sorting instance (which
may barf and die) and append it to the tail;
- Append to the tail each ref_sorting read from the configuration
by parsing in the config callback (which may barf and die);
- See if ref_sorting is null and use ref_sorting_default() instead.
Now the rule is not all that different but is simpler:
- Declare ref_sorting_options string list.
- OPT_REF_SORT() macro will append it to the string list;
- Append to the string list the sort key read from the
configuration;
- call ref_sorting_options() to turn the string list to ref_sorting
structure (which also deals with the default value).
As side effects, this change also cleans up a few issues:
- 95be717c (parse_opt_ref_sorting: always use with NONEG flag,
2019-03-20) muses that "git for-each-ref --no-sort" should simply
clear the sort keys accumulated so far; it now does.
- The implementation detail of "struct ref_sorting" and the helper
function parse_ref_sorting() can now be private to the ref-filter
API implementation.
- If you set branch.sort to a bogus value, the any "git branch"
invocation, not only the listing mode, would abort with the
original code; now it doesn't
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20 21:23:53 +02:00
|
|
|
string_list_append(cb, value);
|
2014-07-16 23:48:02 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-03-22 21:41:26 +01:00
|
|
|
if (!strcmp(var, "tag.forcesignannotated")) {
|
|
|
|
force_sign_annotate = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-11-30 21:55:40 +01:00
|
|
|
if (starts_with(var, "column."))
|
2012-04-13 12:54:41 +02:00
|
|
|
return git_column_config(var, value, "tag", &colopts);
|
tag: respect color.ui config
Since 11b087adfd (ref-filter: consult want_color() before
emitting colors, 2017-07-13), we expect that setting
"color.ui" to "always" will enable color tag formats even
without a tty. As that commit was built on top of
136c8c8b8f (color: check color.ui in git_default_config(),
2017-07-13) from the same series, we didn't need to touch
tag's config parsing at all.
However, since we reverted 136c8c8b8f, we now need to
explicitly call git_color_default_config() to make this
work.
Let's do so, and also restore the test dropped in 0c88bf5050
(provide --color option for all ref-filter users,
2017-10-03). That commit swapped out our "color.ui=always"
test for "--color" in preparation for "always" going away.
But since it is here to stay, we should test both cases.
Note that for-each-ref also lost its color.ui support as
part of reverting 136c8c8b8f. But as a plumbing command, it
should _not_ respect the color.ui config. Since it also
gained a --color option in 0c88bf5050, that's the correct
way to ask it for color. We'll continue to test that, and
confirm that "color.ui" is not respected.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-13 19:26:02 +02:00
|
|
|
return git_color_default_config(var, value, cb);
|
2007-07-20 01:42:28 +02:00
|
|
|
}
|
|
|
|
|
2017-05-07 00:10:08 +02:00
|
|
|
static void write_tag_body(int fd, const struct object_id *oid)
|
2007-11-04 01:11:14 +01:00
|
|
|
{
|
|
|
|
unsigned long size;
|
|
|
|
enum object_type type;
|
2021-02-11 03:08:03 +01:00
|
|
|
char *buf, *sp, *orig;
|
|
|
|
struct strbuf payload = STRBUF_INIT;
|
|
|
|
struct strbuf signature = STRBUF_INIT;
|
2007-11-04 01:11:14 +01:00
|
|
|
|
2023-03-28 15:58:50 +02:00
|
|
|
orig = buf = repo_read_object_file(the_repository, oid, &type, &size);
|
2007-11-04 01:11:14 +01:00
|
|
|
if (!buf)
|
|
|
|
return;
|
2021-02-11 03:08:03 +01:00
|
|
|
if (parse_signature(buf, size, &payload, &signature)) {
|
|
|
|
buf = payload.buf;
|
|
|
|
size = payload.len;
|
|
|
|
}
|
2007-11-04 01:11:14 +01:00
|
|
|
/* skip header */
|
|
|
|
sp = strstr(buf, "\n\n");
|
|
|
|
|
|
|
|
if (!sp || !size || type != OBJ_TAG) {
|
|
|
|
free(buf);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
sp += 2; /* skip the 2 LFs */
|
2021-02-11 03:08:03 +01:00
|
|
|
write_or_die(fd, sp, buf + size - sp);
|
2007-11-04 01:11:14 +01:00
|
|
|
|
2021-02-11 03:08:03 +01:00
|
|
|
free(orig);
|
|
|
|
strbuf_release(&payload);
|
|
|
|
strbuf_release(&signature);
|
2007-11-04 01:11:14 +01:00
|
|
|
}
|
|
|
|
|
2017-05-07 00:10:08 +02:00
|
|
|
static int build_tag_object(struct strbuf *buf, int sign, struct object_id *result)
|
2008-12-06 20:40:34 +01:00
|
|
|
{
|
|
|
|
if (sign && do_sign(buf) < 0)
|
2011-02-23 00:42:09 +01:00
|
|
|
return error(_("unable to sign the tag"));
|
2022-02-05 00:48:26 +01:00
|
|
|
if (write_object_file(buf->buf, buf->len, OBJ_TAG, result) < 0)
|
2011-02-23 00:42:09 +01:00
|
|
|
return error(_("unable to write tag file"));
|
2008-12-06 20:40:34 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-12-07 04:01:45 +01:00
|
|
|
struct create_tag_options {
|
|
|
|
unsigned int message_given:1;
|
2018-02-06 09:36:24 +01:00
|
|
|
unsigned int use_editor:1;
|
2011-12-07 04:01:45 +01:00
|
|
|
unsigned int sign;
|
|
|
|
enum {
|
|
|
|
CLEANUP_NONE,
|
|
|
|
CLEANUP_SPACE,
|
|
|
|
CLEANUP_ALL
|
|
|
|
} cleanup_mode;
|
|
|
|
};
|
|
|
|
|
2019-04-04 20:25:15 +02:00
|
|
|
static const char message_advice_nested_tag[] =
|
2019-05-08 21:16:41 +02:00
|
|
|
N_("You have created a nested tag. The object referred to by your new tag is\n"
|
2019-04-04 20:25:15 +02:00
|
|
|
"already a tag. If you meant to tag the object that it points to, use:\n"
|
|
|
|
"\n"
|
|
|
|
"\tgit tag -f %s %s^{}");
|
|
|
|
|
|
|
|
static void create_tag(const struct object_id *object, const char *object_ref,
|
|
|
|
const char *tag,
|
2011-12-07 04:01:45 +01:00
|
|
|
struct strbuf *buf, struct create_tag_options *opt,
|
2017-05-07 00:10:08 +02:00
|
|
|
struct object_id *prev, struct object_id *result)
|
2007-07-20 01:42:28 +02:00
|
|
|
{
|
|
|
|
enum object_type type;
|
2017-03-28 21:46:23 +02:00
|
|
|
struct strbuf header = STRBUF_INIT;
|
2008-12-06 20:40:34 +01:00
|
|
|
char *path = NULL;
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2018-04-25 20:20:59 +02:00
|
|
|
type = oid_object_info(the_repository, object, NULL);
|
2007-07-21 14:13:12 +02:00
|
|
|
if (type <= OBJ_NONE)
|
2019-04-04 20:25:13 +02:00
|
|
|
die(_("bad object type."));
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2020-03-02 21:02:00 +01:00
|
|
|
if (type == OBJ_TAG)
|
|
|
|
advise_if_enabled(ADVICE_NESTED_TAG, _(message_advice_nested_tag),
|
|
|
|
tag, object_ref);
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2017-03-28 21:46:23 +02:00
|
|
|
strbuf_addf(&header,
|
|
|
|
"object %s\n"
|
|
|
|
"type %s\n"
|
|
|
|
"tag %s\n"
|
|
|
|
"tagger %s\n\n",
|
2017-05-07 00:10:08 +02:00
|
|
|
oid_to_hex(object),
|
2018-02-14 19:59:24 +01:00
|
|
|
type_name(type),
|
2017-03-28 21:46:23 +02:00
|
|
|
tag,
|
|
|
|
git_committer_info(IDENT_STRICT));
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2018-02-06 09:36:24 +01:00
|
|
|
if (!opt->message_given || opt->use_editor) {
|
2007-07-20 01:42:28 +02:00
|
|
|
int fd;
|
|
|
|
|
|
|
|
/* write the template message before editing: */
|
2008-10-27 11:22:09 +01:00
|
|
|
path = git_pathdup("TAG_EDITMSG");
|
2021-08-25 22:16:46 +02:00
|
|
|
fd = xopen(path, O_CREAT | O_TRUNC | O_WRONLY, 0600);
|
2007-11-04 01:11:14 +01:00
|
|
|
|
2018-02-06 09:36:24 +01:00
|
|
|
if (opt->message_given) {
|
|
|
|
write_or_die(fd, buf->buf, buf->len);
|
|
|
|
strbuf_reset(buf);
|
|
|
|
} else if (!is_null_oid(prev)) {
|
2007-11-04 01:11:14 +01:00
|
|
|
write_tag_body(fd, prev);
|
2013-01-16 20:18:48 +01:00
|
|
|
} else {
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
strbuf_addch(&buf, '\n');
|
|
|
|
if (opt->cleanup_mode == CLEANUP_ALL)
|
2013-08-30 00:03:10 +02:00
|
|
|
strbuf_commented_addf(&buf, _(tag_template), tag, comment_line_char);
|
2013-01-16 20:18:48 +01:00
|
|
|
else
|
2013-08-30 00:03:10 +02:00
|
|
|
strbuf_commented_addf(&buf, _(tag_template_nocleanup), tag, comment_line_char);
|
2013-01-16 20:18:48 +01:00
|
|
|
write_or_die(fd, buf.buf, buf.len);
|
|
|
|
strbuf_release(&buf);
|
|
|
|
}
|
2007-07-20 01:42:28 +02:00
|
|
|
close(fd);
|
|
|
|
|
2008-07-25 18:28:42 +02:00
|
|
|
if (launch_editor(path, buf, NULL)) {
|
|
|
|
fprintf(stderr,
|
2011-02-23 00:42:09 +01:00
|
|
|
_("Please supply the message using either -m or -F option.\n"));
|
2008-07-25 18:28:42 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
2007-07-20 01:42:28 +02:00
|
|
|
}
|
|
|
|
|
2011-12-07 04:01:45 +01:00
|
|
|
if (opt->cleanup_mode != CLEANUP_NONE)
|
2015-10-16 17:16:42 +02:00
|
|
|
strbuf_stripspace(buf, opt->cleanup_mode == CLEANUP_ALL);
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2011-12-07 04:01:45 +01:00
|
|
|
if (!opt->message_given && !buf->len)
|
2011-02-23 00:42:09 +01:00
|
|
|
die(_("no tag message?"));
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2017-03-28 21:46:23 +02:00
|
|
|
strbuf_insert(buf, 0, header.buf, header.len);
|
|
|
|
strbuf_release(&header);
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2011-12-07 04:01:45 +01:00
|
|
|
if (build_tag_object(buf, opt->sign, result) < 0) {
|
2008-12-06 20:40:34 +01:00
|
|
|
if (path)
|
2011-02-23 00:42:09 +01:00
|
|
|
fprintf(stderr, _("The tag message has been left in %s\n"),
|
2008-12-06 20:40:34 +01:00
|
|
|
path);
|
|
|
|
exit(128);
|
|
|
|
}
|
|
|
|
if (path) {
|
2009-04-29 23:22:56 +02:00
|
|
|
unlink_or_warn(path);
|
2008-12-06 20:40:34 +01:00
|
|
|
free(path);
|
|
|
|
}
|
2007-07-20 01:42:28 +02:00
|
|
|
}
|
|
|
|
|
2017-05-07 00:10:08 +02:00
|
|
|
static void create_reflog_msg(const struct object_id *oid, struct strbuf *sb)
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
{
|
|
|
|
enum object_type type;
|
|
|
|
struct commit *c;
|
|
|
|
char *buf;
|
|
|
|
unsigned long size;
|
|
|
|
int subject_len = 0;
|
|
|
|
const char *subject_start;
|
|
|
|
|
|
|
|
char *rla = getenv("GIT_REFLOG_ACTION");
|
|
|
|
if (rla) {
|
|
|
|
strbuf_addstr(sb, rla);
|
|
|
|
} else {
|
2017-04-30 23:32:47 +02:00
|
|
|
strbuf_addstr(sb, "tag: tagging ");
|
strbuf: convert strbuf_add_unique_abbrev to use struct object_id
Convert the declaration and definition of strbuf_add_unique_abbrev to
make it take a pointer to struct object_id. Predeclare the struct in
strbuf.h, as cache.h includes strbuf.h before it declares the struct,
and otherwise the struct declaration would have the wrong scope.
Apply the following semantic patch, along with the standard object_id
transforms, to adjust the callers:
@@
expression E1, E2, E3;
@@
- strbuf_add_unique_abbrev(E1, E2.hash, E3);
+ strbuf_add_unique_abbrev(E1, &E2, E3);
@@
expression E1, E2, E3;
@@
- strbuf_add_unique_abbrev(E1, E2->hash, E3);
+ strbuf_add_unique_abbrev(E1, E2, E3);
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 03:27:28 +01:00
|
|
|
strbuf_add_unique_abbrev(sb, oid, DEFAULT_ABBREV);
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_addstr(sb, " (");
|
2018-04-25 20:20:59 +02:00
|
|
|
type = oid_object_info(the_repository, oid, NULL);
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
switch (type) {
|
|
|
|
default:
|
2017-04-30 23:32:47 +02:00
|
|
|
strbuf_addstr(sb, "object of unknown type");
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
break;
|
|
|
|
case OBJ_COMMIT:
|
2023-03-28 15:58:50 +02:00
|
|
|
if ((buf = repo_read_object_file(the_repository, oid, &type, &size))) {
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
subject_len = find_commit_subject(buf, &subject_start);
|
|
|
|
strbuf_insert(sb, sb->len, subject_start, subject_len);
|
|
|
|
} else {
|
2017-04-30 23:32:47 +02:00
|
|
|
strbuf_addstr(sb, "commit object");
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
}
|
|
|
|
free(buf);
|
|
|
|
|
2022-05-02 18:50:37 +02:00
|
|
|
if ((c = lookup_commit_reference(the_repository, oid)))
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
strbuf_addf(sb, ", %s", show_date(c->date, 0, DATE_MODE(SHORT)));
|
|
|
|
break;
|
|
|
|
case OBJ_TREE:
|
2017-04-30 23:32:47 +02:00
|
|
|
strbuf_addstr(sb, "tree object");
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
break;
|
|
|
|
case OBJ_BLOB:
|
2017-04-30 23:32:47 +02:00
|
|
|
strbuf_addstr(sb, "blob object");
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
break;
|
|
|
|
case OBJ_TAG:
|
2017-04-30 23:32:47 +02:00
|
|
|
strbuf_addstr(sb, "other tag object");
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
strbuf_addch(sb, ')');
|
|
|
|
}
|
|
|
|
|
2007-11-23 08:16:51 +01:00
|
|
|
struct msg_arg {
|
|
|
|
int given;
|
|
|
|
struct strbuf buf;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int parse_msg_arg(const struct option *opt, const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct msg_arg *msg = 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 07:45:42 +01:00
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
|
2007-11-23 08:16:51 +01:00
|
|
|
if (!arg)
|
|
|
|
return -1;
|
|
|
|
if (msg->buf.len)
|
|
|
|
strbuf_addstr(&(msg->buf), "\n\n");
|
|
|
|
strbuf_addstr(&(msg->buf), arg);
|
|
|
|
msg->given = 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-05-10 01:36:36 +02:00
|
|
|
static int strbuf_check_tag_ref(struct strbuf *sb, const char *name)
|
|
|
|
{
|
|
|
|
if (name[0] == '-')
|
2011-09-15 23:10:25 +02:00
|
|
|
return -1;
|
2011-05-10 01:36:36 +02:00
|
|
|
|
|
|
|
strbuf_reset(sb);
|
|
|
|
strbuf_addf(sb, "refs/tags/%s", name);
|
|
|
|
|
2011-09-15 23:10:25 +02:00
|
|
|
return check_refname_format(sb->buf, 0);
|
2011-05-10 01:36:36 +02:00
|
|
|
}
|
|
|
|
|
2007-07-20 01:42:28 +02:00
|
|
|
int cmd_tag(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
2008-10-09 21:12:12 +02:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2011-05-10 01:36:36 +02:00
|
|
|
struct strbuf ref = STRBUF_INIT;
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
struct strbuf reflog_msg = STRBUF_INIT;
|
2017-05-07 00:10:08 +02:00
|
|
|
struct object_id object, prev;
|
2007-07-20 01:42:28 +02:00
|
|
|
const char *object_ref, *tag;
|
2011-12-07 04:01:45 +01:00
|
|
|
struct create_tag_options opt;
|
|
|
|
char *cleanup_arg = NULL;
|
2015-07-21 23:04:55 +02:00
|
|
|
int create_reflog = 0;
|
2015-09-10 17:48:27 +02:00
|
|
|
int annotate = 0, force = 0;
|
2016-03-22 21:41:26 +01:00
|
|
|
int cmdmode = 0, create_tag_object = 0;
|
parse-options: consistently allocate memory in fix_filename()
When handling OPT_FILENAME(), we have to stick the "prefix" (if any) in
front of the filename to make up for the fact that Git has chdir()'d to
the top of the repository. We can do this with prefix_filename(), but
there are a few special cases we handle ourselves.
Unfortunately the memory allocation is inconsistent here; if we do make
it to prefix_filename(), we'll allocate a string which the caller must
free to avoid a leak. But if we hit our special cases, we'll return the
string as-is, and a caller which tries to free it will crash. So there's
no way to win.
Let's consistently allocate, so that callers can do the right thing.
There are now three cases to care about in the function (and hence a
three-armed if/else):
1. we got a NULL input (and should leave it as NULL, though arguably
this is the sign of a bug; let's keep the status quo for now and we
can pick at that scab later)
2. we hit a special case that means we leave the name intact; we
should duplicate the string. This includes our special "-"
matching. Prior to this patch, it also included empty prefixes and
absolute filenames. But we can observe that prefix_filename()
already handles these, so we don't need to detect them.
3. everything else goes to prefix_filename()
I've dropped the "const" from the "char **file" parameter to indicate
that we're allocating, though in practice it's not really important.
This is all being shuffled through a void pointer via opt->value before
it hits code which ever looks at the string. And it's even a bit weird,
because we are really taking _in_ a const string and using the same
out-parameter for a non-const string. A better function signature would
be:
static char *fix_filename(const char *prefix, const char *file);
but that would mean the caller dereferences the double-pointer (and the
NULL check is currently handled inside this function). So I took the
path of least-change here.
Note that we have to fix several callers in this commit, too, or we'll
break the leak-checking tests. These are "new" leaks in the sense that
they are now triggered by the test suite, but these spots have always
been leaky when Git is run in a subdirectory of the repository. I fixed
all of the cases that trigger with GIT_TEST_PASSING_SANITIZE_LEAK. There
may be others in scripts that have other leaks, but we can fix them
later along with those other leaks (and again, you _couldn't_ fix them
before this patch, so this is the necessary first step).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:31:22 +01:00
|
|
|
char *msgfile = NULL;
|
|
|
|
const char *keyid = NULL;
|
2021-10-20 20:27:19 +02:00
|
|
|
struct msg_arg msg = { .buf = STRBUF_INIT };
|
2014-04-17 00:30:41 +02:00
|
|
|
struct ref_transaction *transaction;
|
|
|
|
struct strbuf err = STRBUF_INIT;
|
2015-09-10 17:48:27 +02:00
|
|
|
struct ref_filter filter;
|
for-each-ref: delay parsing of --sort=<atom> options
The for-each-ref family of commands invoke parsers immediately when
it sees each --sort=<atom> option, and die before even seeing the
other options on the command line when the <atom> is unrecognised.
Instead, accumulate them in a string list, and have them parsed into
a ref_sorting structure after the command line parsing is done. As
a consequence, "git branch --sort=bogus -h" used to fail to give the
brief help, which arguably may have been a feature, now does so,
which is more consistent with how other options work.
The patch is smaller than the actual extent of the "damage" to the
codebase, thanks to the fact that the original code consistently
used OPT_REF_SORT() macro to handle command line options. We only
needed to replace the variable used for the list, and implementation
of the callback function used in the macro.
The old rule was for the users of the API to:
- Declare ref_sorting and ref_sorting_tail variables;
- OPT_REF_SORT() macro will instantiate ref_sorting instance (which
may barf and die) and append it to the tail;
- Append to the tail each ref_sorting read from the configuration
by parsing in the config callback (which may barf and die);
- See if ref_sorting is null and use ref_sorting_default() instead.
Now the rule is not all that different but is simpler:
- Declare ref_sorting_options string list.
- OPT_REF_SORT() macro will append it to the string list;
- Append to the string list the sort key read from the
configuration;
- call ref_sorting_options() to turn the string list to ref_sorting
structure (which also deals with the default value).
As side effects, this change also cleans up a few issues:
- 95be717c (parse_opt_ref_sorting: always use with NONEG flag,
2019-03-20) muses that "git for-each-ref --no-sort" should simply
clear the sort keys accumulated so far; it now does.
- The implementation detail of "struct ref_sorting" and the helper
function parse_ref_sorting() can now be private to the ref-filter
API implementation.
- If you set branch.sort to a bogus value, the any "git branch"
invocation, not only the listing mode, would abort with the
original code; now it doesn't
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20 21:23:53 +02:00
|
|
|
struct ref_sorting *sorting;
|
|
|
|
struct string_list sorting_options = STRING_LIST_INIT_DUP;
|
2017-07-13 17:01:18 +02:00
|
|
|
struct ref_format format = REF_FORMAT_INIT;
|
2016-12-04 03:52:25 +01:00
|
|
|
int icase = 0;
|
2018-02-06 09:36:24 +01:00
|
|
|
int edit_flag = 0;
|
2007-11-09 14:42:56 +01:00
|
|
|
struct option options[] = {
|
2013-07-30 21:31:27 +02:00
|
|
|
OPT_CMDMODE('l', "list", &cmdmode, N_("list tag names"), 'l'),
|
2015-09-10 17:48:27 +02:00
|
|
|
{ OPTION_INTEGER, 'n', NULL, &filter.lines, N_("n"),
|
2012-08-20 14:32:47 +02:00
|
|
|
N_("print <n> lines of each tag message"),
|
2007-11-09 14:42:56 +01:00
|
|
|
PARSE_OPT_OPTARG, NULL, 1 },
|
2013-07-30 21:31:27 +02:00
|
|
|
OPT_CMDMODE('d', "delete", &cmdmode, N_("delete tags"), 'd'),
|
|
|
|
OPT_CMDMODE('v', "verify", &cmdmode, N_("verify tags"), 'v'),
|
2007-11-09 14:42:56 +01:00
|
|
|
|
2012-08-20 14:32:47 +02:00
|
|
|
OPT_GROUP(N_("Tag creation options")),
|
2013-08-03 13:51:19 +02:00
|
|
|
OPT_BOOL('a', "annotate", &annotate,
|
2012-08-20 14:32:47 +02:00
|
|
|
N_("annotated tag, needs a message")),
|
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 10:36:28 +02:00
|
|
|
OPT_CALLBACK_F('m', "message", &msg, N_("message"),
|
|
|
|
N_("tag message"), PARSE_OPT_NONEG, parse_msg_arg),
|
2012-08-20 14:32:47 +02:00
|
|
|
OPT_FILENAME('F', "file", &msgfile, N_("read message from file")),
|
2018-02-06 09:36:24 +01:00
|
|
|
OPT_BOOL('e', "edit", &edit_flag, N_("force edit of tag message")),
|
2013-08-03 13:51:19 +02:00
|
|
|
OPT_BOOL('s', "sign", &opt.sign, N_("annotated and GPG-signed tag")),
|
2019-04-17 12:23:26 +02:00
|
|
|
OPT_CLEANUP(&cleanup_arg),
|
2014-03-23 23:58:12 +01:00
|
|
|
OPT_STRING('u', "local-user", &keyid, N_("key-id"),
|
2012-08-20 14:32:47 +02:00
|
|
|
N_("use another key to sign the tag")),
|
2018-02-09 12:01:42 +01:00
|
|
|
OPT__FORCE(&force, N_("replace the tag if exists"), 0),
|
2015-09-11 18:04:13 +02:00
|
|
|
OPT_BOOL(0, "create-reflog", &create_reflog, N_("create a reflog")),
|
2015-03-12 19:15:09 +01:00
|
|
|
|
|
|
|
OPT_GROUP(N_("Tag listing options")),
|
2012-08-20 14:32:47 +02:00
|
|
|
OPT_COLUMN(0, "column", &colopts, N_("show tag list in columns")),
|
2015-09-10 17:48:27 +02:00
|
|
|
OPT_CONTAINS(&filter.with_commit, N_("print only tags that contain the commit")),
|
ref-filter: add --no-contains option to tag/branch/for-each-ref
Change the tag, branch & for-each-ref commands to have a --no-contains
option in addition to their longstanding --contains options.
This allows for finding the last-good rollout tag given a known-bad
<commit>. Given a hypothetically bad commit cf5c7253e0, the git
version to revert to can be found with this hacky two-liner:
(git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') |
sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10
With this new --no-contains option the same can be achieved with:
git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10
As the filtering machinery is shared between the tag, branch &
for-each-ref commands, implement this for those commands too. A
practical use for this with "branch" is e.g. finding branches which
were branched off between v2.8.0 and v2.10.0:
git branch --contains v2.8.0 --no-contains v2.10.0
The "describe" command also has a --contains option, but its semantics
are unrelated to what tag/branch/for-each-ref use --contains for. A
--no-contains option for "describe" wouldn't make any sense, other
than being exactly equivalent to not supplying --contains at all,
which would be confusing at best.
Add a --without option to "tag" as an alias for --no-contains, for
consistency with --with and --contains. The --with option is
undocumented, and possibly the only user of it is
Junio (<xmqqefy71iej.fsf@gitster.mtv.corp.google.com>). But it's
trivial to support, so let's do that.
The additions to the the test suite are inverse copies of the
corresponding --contains tests. With this change --no-contains for
tag, branch & for-each-ref is just as well tested as the existing
--contains option.
In addition to those tests, add a test for "tag" which asserts that
--no-contains won't find tree/blob tags, which is slightly
unintuitive, but consistent with how --contains works & is documented.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24 19:40:57 +01:00
|
|
|
OPT_NO_CONTAINS(&filter.no_commit, N_("print only tags that don't contain the commit")),
|
2015-09-10 17:48:27 +02:00
|
|
|
OPT_WITH(&filter.with_commit, N_("print only tags that contain the commit")),
|
ref-filter: add --no-contains option to tag/branch/for-each-ref
Change the tag, branch & for-each-ref commands to have a --no-contains
option in addition to their longstanding --contains options.
This allows for finding the last-good rollout tag given a known-bad
<commit>. Given a hypothetically bad commit cf5c7253e0, the git
version to revert to can be found with this hacky two-liner:
(git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') |
sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10
With this new --no-contains option the same can be achieved with:
git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10
As the filtering machinery is shared between the tag, branch &
for-each-ref commands, implement this for those commands too. A
practical use for this with "branch" is e.g. finding branches which
were branched off between v2.8.0 and v2.10.0:
git branch --contains v2.8.0 --no-contains v2.10.0
The "describe" command also has a --contains option, but its semantics
are unrelated to what tag/branch/for-each-ref use --contains for. A
--no-contains option for "describe" wouldn't make any sense, other
than being exactly equivalent to not supplying --contains at all,
which would be confusing at best.
Add a --without option to "tag" as an alias for --no-contains, for
consistency with --with and --contains. The --with option is
undocumented, and possibly the only user of it is
Junio (<xmqqefy71iej.fsf@gitster.mtv.corp.google.com>). But it's
trivial to support, so let's do that.
The additions to the the test suite are inverse copies of the
corresponding --contains tests. With this change --no-contains for
tag, branch & for-each-ref is just as well tested as the existing
--contains option.
In addition to those tests, add a test for "tag" which asserts that
--no-contains won't find tree/blob tags, which is slightly
unintuitive, but consistent with how --contains works & is documented.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24 19:40:57 +01:00
|
|
|
OPT_WITHOUT(&filter.no_commit, N_("print only tags that don't contain the commit")),
|
2015-09-10 18:22:49 +02:00
|
|
|
OPT_MERGED(&filter, N_("print only tags that are merged")),
|
|
|
|
OPT_NO_MERGED(&filter, N_("print only tags that are not merged")),
|
2023-04-07 19:53:16 +02:00
|
|
|
OPT_BOOL(0, "omit-empty", &omit_empty,
|
|
|
|
N_("do not output a newline after empty formatted refs")),
|
for-each-ref: delay parsing of --sort=<atom> options
The for-each-ref family of commands invoke parsers immediately when
it sees each --sort=<atom> option, and die before even seeing the
other options on the command line when the <atom> is unrecognised.
Instead, accumulate them in a string list, and have them parsed into
a ref_sorting structure after the command line parsing is done. As
a consequence, "git branch --sort=bogus -h" used to fail to give the
brief help, which arguably may have been a feature, now does so,
which is more consistent with how other options work.
The patch is smaller than the actual extent of the "damage" to the
codebase, thanks to the fact that the original code consistently
used OPT_REF_SORT() macro to handle command line options. We only
needed to replace the variable used for the list, and implementation
of the callback function used in the macro.
The old rule was for the users of the API to:
- Declare ref_sorting and ref_sorting_tail variables;
- OPT_REF_SORT() macro will instantiate ref_sorting instance (which
may barf and die) and append it to the tail;
- Append to the tail each ref_sorting read from the configuration
by parsing in the config callback (which may barf and die);
- See if ref_sorting is null and use ref_sorting_default() instead.
Now the rule is not all that different but is simpler:
- Declare ref_sorting_options string list.
- OPT_REF_SORT() macro will append it to the string list;
- Append to the string list the sort key read from the
configuration;
- call ref_sorting_options() to turn the string list to ref_sorting
structure (which also deals with the default value).
As side effects, this change also cleans up a few issues:
- 95be717c (parse_opt_ref_sorting: always use with NONEG flag,
2019-03-20) muses that "git for-each-ref --no-sort" should simply
clear the sort keys accumulated so far; it now does.
- The implementation detail of "struct ref_sorting" and the helper
function parse_ref_sorting() can now be private to the ref-filter
API implementation.
- If you set branch.sort to a bogus value, the any "git branch"
invocation, not only the listing mode, would abort with the
original code; now it doesn't
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20 21:23:53 +02:00
|
|
|
OPT_REF_SORT(&sorting_options),
|
2009-01-26 15:13:25 +01:00
|
|
|
{
|
2015-09-10 17:48:27 +02:00
|
|
|
OPTION_CALLBACK, 0, "points-at", &filter.points_at, N_("object"),
|
2017-03-24 19:40:56 +01:00
|
|
|
N_("print only tags of the object"), PARSE_OPT_LASTARG_DEFAULT,
|
|
|
|
parse_opt_object_name, (intptr_t) "HEAD"
|
2012-02-09 00:03:43 +01:00
|
|
|
},
|
2017-07-13 17:01:18 +02:00
|
|
|
OPT_STRING( 0 , "format", &format.format, N_("format"),
|
|
|
|
N_("format to use for the output")),
|
2017-10-03 15:45:47 +02:00
|
|
|
OPT__COLOR(&format.use_color, N_("respect format colors")),
|
2016-12-04 03:52:25 +01:00
|
|
|
OPT_BOOL('i', "ignore-case", &icase, N_("sorting and filtering are case insensitive")),
|
2007-11-09 14:42:56 +01:00
|
|
|
OPT_END()
|
|
|
|
};
|
2021-10-20 20:27:19 +02:00
|
|
|
int ret = 0;
|
2022-01-05 21:02:18 +01:00
|
|
|
const char *only_in_list = NULL;
|
2007-11-09 14:42:56 +01:00
|
|
|
|
2017-01-10 09:49:51 +01:00
|
|
|
setup_ref_filter_porcelain_msg();
|
|
|
|
|
for-each-ref: delay parsing of --sort=<atom> options
The for-each-ref family of commands invoke parsers immediately when
it sees each --sort=<atom> option, and die before even seeing the
other options on the command line when the <atom> is unrecognised.
Instead, accumulate them in a string list, and have them parsed into
a ref_sorting structure after the command line parsing is done. As
a consequence, "git branch --sort=bogus -h" used to fail to give the
brief help, which arguably may have been a feature, now does so,
which is more consistent with how other options work.
The patch is smaller than the actual extent of the "damage" to the
codebase, thanks to the fact that the original code consistently
used OPT_REF_SORT() macro to handle command line options. We only
needed to replace the variable used for the list, and implementation
of the callback function used in the macro.
The old rule was for the users of the API to:
- Declare ref_sorting and ref_sorting_tail variables;
- OPT_REF_SORT() macro will instantiate ref_sorting instance (which
may barf and die) and append it to the tail;
- Append to the tail each ref_sorting read from the configuration
by parsing in the config callback (which may barf and die);
- See if ref_sorting is null and use ref_sorting_default() instead.
Now the rule is not all that different but is simpler:
- Declare ref_sorting_options string list.
- OPT_REF_SORT() macro will append it to the string list;
- Append to the string list the sort key read from the
configuration;
- call ref_sorting_options() to turn the string list to ref_sorting
structure (which also deals with the default value).
As side effects, this change also cleans up a few issues:
- 95be717c (parse_opt_ref_sorting: always use with NONEG flag,
2019-03-20) muses that "git for-each-ref --no-sort" should simply
clear the sort keys accumulated so far; it now does.
- The implementation detail of "struct ref_sorting" and the helper
function parse_ref_sorting() can now be private to the ref-filter
API implementation.
- If you set branch.sort to a bogus value, the any "git branch"
invocation, not only the listing mode, would abort with the
original code; now it doesn't
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20 21:23:53 +02:00
|
|
|
git_config(git_tag_config, &sorting_options);
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2011-12-07 04:01:45 +01:00
|
|
|
memset(&opt, 0, sizeof(opt));
|
2015-09-10 17:48:27 +02:00
|
|
|
memset(&filter, 0, sizeof(filter));
|
|
|
|
filter.lines = -1;
|
2019-06-05 23:33:21 +02:00
|
|
|
opt.sign = -1;
|
2011-12-07 04:01:45 +01:00
|
|
|
|
2009-05-23 20:53:12 +02:00
|
|
|
argc = parse_options(argc, argv, prefix, options, git_tag_usage, 0);
|
2007-07-20 01:42:28 +02:00
|
|
|
|
tag: implicitly supply --list given another list-like option
Change the "tag" command to implicitly turn on its --list mode when
provided with a list-like option such as --contains, --points-at etc.
This is for consistency with how "branch" works. When "branch" is
given a list-like option, such as --contains, it implicitly provides
--list. Before this change "tag" would error out on those sorts of
invocations. I.e. while both of these worked for "branch":
git branch --contains v2.8.0 <pattern>
git branch --list --contains v2.8.0 <pattern>
Only the latter form worked for "tag":
git tag --contains v2.8.0 '*rc*'
git tag --list --contains v2.8.0 '*rc*'
Now "tag", like "branch", will implicitly supply --list when a
list-like option is provided, and no other conflicting non-list
options (such as -d) are present on the command-line.
Spelunking through the history via:
git log --reverse -p -G'only allowed with' -- '*builtin*tag*c'
Reveals that there was no good reason for not allowing this in the
first place. The --contains option added in 32c35cfb1e ("git-tag: Add
--contains option", 2009-01-26) made this an error. All the other
subsequent list-like options that were added copied its pattern of
making this usage an error.
The only tests that break as a result of this change are tests that
were explicitly checking that this "branch-like" usage wasn't
permitted. Change those failing tests to check that this invocation
mode is permitted, add extra tests for the list-like options we
weren't testing, and tests to ensure that e.g. we don't toggle the
list mode in the presence of other conflicting non-list options.
With this change errors messages such as "--contains option is only
allowed with -l" don't make sense anymore, since options like
--contain turn on -l. Instead we error out when list-like options such
as --contain are used in conjunction with conflicting options such as
-d or -v.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24 19:40:55 +01:00
|
|
|
if (!cmdmode) {
|
|
|
|
if (argc == 0)
|
|
|
|
cmdmode = 'l';
|
ref-filter: add --no-contains option to tag/branch/for-each-ref
Change the tag, branch & for-each-ref commands to have a --no-contains
option in addition to their longstanding --contains options.
This allows for finding the last-good rollout tag given a known-bad
<commit>. Given a hypothetically bad commit cf5c7253e0, the git
version to revert to can be found with this hacky two-liner:
(git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') |
sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10
With this new --no-contains option the same can be achieved with:
git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10
As the filtering machinery is shared between the tag, branch &
for-each-ref commands, implement this for those commands too. A
practical use for this with "branch" is e.g. finding branches which
were branched off between v2.8.0 and v2.10.0:
git branch --contains v2.8.0 --no-contains v2.10.0
The "describe" command also has a --contains option, but its semantics
are unrelated to what tag/branch/for-each-ref use --contains for. A
--no-contains option for "describe" wouldn't make any sense, other
than being exactly equivalent to not supplying --contains at all,
which would be confusing at best.
Add a --without option to "tag" as an alias for --no-contains, for
consistency with --with and --contains. The --with option is
undocumented, and possibly the only user of it is
Junio (<xmqqefy71iej.fsf@gitster.mtv.corp.google.com>). But it's
trivial to support, so let's do that.
The additions to the the test suite are inverse copies of the
corresponding --contains tests. With this change --no-contains for
tag, branch & for-each-ref is just as well tested as the existing
--contains option.
In addition to those tests, add a test for "tag" which asserts that
--no-contains won't find tree/blob tags, which is slightly
unintuitive, but consistent with how --contains works & is documented.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24 19:40:57 +01:00
|
|
|
else if (filter.with_commit || filter.no_commit ||
|
2020-09-16 04:08:40 +02:00
|
|
|
filter.reachable_from || filter.unreachable_from ||
|
|
|
|
filter.points_at.nr || filter.lines != -1)
|
tag: implicitly supply --list given another list-like option
Change the "tag" command to implicitly turn on its --list mode when
provided with a list-like option such as --contains, --points-at etc.
This is for consistency with how "branch" works. When "branch" is
given a list-like option, such as --contains, it implicitly provides
--list. Before this change "tag" would error out on those sorts of
invocations. I.e. while both of these worked for "branch":
git branch --contains v2.8.0 <pattern>
git branch --list --contains v2.8.0 <pattern>
Only the latter form worked for "tag":
git tag --contains v2.8.0 '*rc*'
git tag --list --contains v2.8.0 '*rc*'
Now "tag", like "branch", will implicitly supply --list when a
list-like option is provided, and no other conflicting non-list
options (such as -d) are present on the command-line.
Spelunking through the history via:
git log --reverse -p -G'only allowed with' -- '*builtin*tag*c'
Reveals that there was no good reason for not allowing this in the
first place. The --contains option added in 32c35cfb1e ("git-tag: Add
--contains option", 2009-01-26) made this an error. All the other
subsequent list-like options that were added copied its pattern of
making this usage an error.
The only tests that break as a result of this change are tests that
were explicitly checking that this "branch-like" usage wasn't
permitted. Change those failing tests to check that this invocation
mode is permitted, add extra tests for the list-like options we
weren't testing, and tests to ensure that e.g. we don't toggle the
list mode in the presence of other conflicting non-list options.
With this change errors messages such as "--contains option is only
allowed with -l" don't make sense anymore, since options like
--contain turn on -l. Instead we error out when list-like options such
as --contain are used in conjunction with conflicting options such as
-d or -v.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24 19:40:55 +01:00
|
|
|
cmdmode = 'l';
|
|
|
|
}
|
2007-11-26 00:21:42 +01:00
|
|
|
|
2017-08-02 21:40:53 +02:00
|
|
|
if (cmdmode == 'l')
|
2017-08-02 21:40:54 +02:00
|
|
|
setup_auto_pager("tag", 1);
|
2017-08-02 21:40:53 +02:00
|
|
|
|
2019-06-05 23:33:21 +02:00
|
|
|
if (opt.sign == -1)
|
|
|
|
opt.sign = cmdmode ? 0 : config_sign_tag > 0;
|
|
|
|
|
|
|
|
if (keyid) {
|
|
|
|
opt.sign = 1;
|
|
|
|
set_signing_key(keyid);
|
|
|
|
}
|
|
|
|
create_tag_object = (opt.sign || annotate || msg.given || msgfile);
|
|
|
|
|
2016-03-22 21:41:26 +01:00
|
|
|
if ((create_tag_object || force) && (cmdmode != 0))
|
2008-11-05 00:20:31 +01:00
|
|
|
usage_with_options(git_tag_usage, options);
|
|
|
|
|
2012-04-13 12:54:41 +02:00
|
|
|
finalize_colopts(&colopts, -1);
|
2015-09-10 17:48:27 +02:00
|
|
|
if (cmdmode == 'l' && filter.lines != -1) {
|
2012-04-13 12:54:41 +02:00
|
|
|
if (explicitly_enable_column(colopts))
|
2022-01-05 21:02:16 +01:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--column", "-n");
|
2012-04-13 12:54:41 +02:00
|
|
|
colopts = 0;
|
|
|
|
}
|
for-each-ref: delay parsing of --sort=<atom> options
The for-each-ref family of commands invoke parsers immediately when
it sees each --sort=<atom> option, and die before even seeing the
other options on the command line when the <atom> is unrecognised.
Instead, accumulate them in a string list, and have them parsed into
a ref_sorting structure after the command line parsing is done. As
a consequence, "git branch --sort=bogus -h" used to fail to give the
brief help, which arguably may have been a feature, now does so,
which is more consistent with how other options work.
The patch is smaller than the actual extent of the "damage" to the
codebase, thanks to the fact that the original code consistently
used OPT_REF_SORT() macro to handle command line options. We only
needed to replace the variable used for the list, and implementation
of the callback function used in the macro.
The old rule was for the users of the API to:
- Declare ref_sorting and ref_sorting_tail variables;
- OPT_REF_SORT() macro will instantiate ref_sorting instance (which
may barf and die) and append it to the tail;
- Append to the tail each ref_sorting read from the configuration
by parsing in the config callback (which may barf and die);
- See if ref_sorting is null and use ref_sorting_default() instead.
Now the rule is not all that different but is simpler:
- Declare ref_sorting_options string list.
- OPT_REF_SORT() macro will append it to the string list;
- Append to the string list the sort key read from the
configuration;
- call ref_sorting_options() to turn the string list to ref_sorting
structure (which also deals with the default value).
As side effects, this change also cleans up a few issues:
- 95be717c (parse_opt_ref_sorting: always use with NONEG flag,
2019-03-20) muses that "git for-each-ref --no-sort" should simply
clear the sort keys accumulated so far; it now does.
- The implementation detail of "struct ref_sorting" and the helper
function parse_ref_sorting() can now be private to the ref-filter
API implementation.
- If you set branch.sort to a bogus value, the any "git branch"
invocation, not only the listing mode, would abort with the
original code; now it doesn't
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20 21:23:53 +02:00
|
|
|
sorting = ref_sorting_options(&sorting_options);
|
2021-01-07 10:51:51 +01:00
|
|
|
ref_sorting_set_sort_flags_all(sorting, REF_SORTING_ICASE, icase);
|
2016-12-04 03:52:25 +01:00
|
|
|
filter.ignore_case = icase;
|
2013-07-30 21:31:27 +02:00
|
|
|
if (cmdmode == 'l') {
|
2012-04-13 12:54:41 +02:00
|
|
|
if (column_active(colopts)) {
|
|
|
|
struct column_options copts;
|
|
|
|
memset(&copts, 0, sizeof(copts));
|
|
|
|
copts.padding = 2;
|
|
|
|
run_column_filter(colopts, &copts);
|
|
|
|
}
|
2015-09-10 17:48:27 +02:00
|
|
|
filter.name_patterns = argv;
|
2017-07-13 17:01:18 +02:00
|
|
|
ret = list_tags(&filter, sorting, &format);
|
2012-04-13 12:54:41 +02:00
|
|
|
if (column_active(colopts))
|
|
|
|
stop_column_filter();
|
2021-10-20 20:27:19 +02:00
|
|
|
goto cleanup;
|
2012-04-13 12:54:41 +02:00
|
|
|
}
|
2015-09-10 17:48:27 +02:00
|
|
|
if (filter.lines != -1)
|
2022-01-05 21:02:18 +01:00
|
|
|
only_in_list = "-n";
|
|
|
|
else if (filter.with_commit)
|
|
|
|
only_in_list = "--contains";
|
|
|
|
else if (filter.no_commit)
|
|
|
|
only_in_list = "--no-contains";
|
|
|
|
else if (filter.points_at.nr)
|
|
|
|
only_in_list = "--points-at";
|
|
|
|
else if (filter.reachable_from)
|
|
|
|
only_in_list = "--merged";
|
|
|
|
else if (filter.unreachable_from)
|
|
|
|
only_in_list = "--no-merged";
|
|
|
|
if (only_in_list)
|
|
|
|
die(_("the '%s' option is only allowed in list mode"), only_in_list);
|
2021-10-20 20:27:19 +02:00
|
|
|
if (cmdmode == 'd') {
|
|
|
|
ret = delete_tags(argv);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2017-01-18 00:37:21 +01:00
|
|
|
if (cmdmode == 'v') {
|
2017-07-13 17:01:18 +02:00
|
|
|
if (format.format && verify_ref_format(&format))
|
2017-07-13 16:56:10 +02:00
|
|
|
usage_with_options(git_tag_usage, options);
|
2021-10-20 20:27:19 +02:00
|
|
|
ret = for_each_tag_name(argv, verify_tag, &format);
|
|
|
|
goto cleanup;
|
2017-01-18 00:37:21 +01:00
|
|
|
}
|
2007-11-09 14:42:56 +01:00
|
|
|
|
2007-11-23 08:16:51 +01:00
|
|
|
if (msg.given || msgfile) {
|
|
|
|
if (msg.given && msgfile)
|
2022-01-05 21:02:16 +01:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "-F", "-m");
|
2007-11-23 08:16:51 +01:00
|
|
|
if (msg.given)
|
|
|
|
strbuf_addbuf(&buf, &(msg.buf));
|
2007-11-09 14:42:56 +01:00
|
|
|
else {
|
|
|
|
if (!strcmp(msgfile, "-")) {
|
2007-09-27 15:25:55 +02:00
|
|
|
if (strbuf_read(&buf, 0, 1024) < 0)
|
2011-02-23 00:42:09 +01:00
|
|
|
die_errno(_("cannot read '%s'"), msgfile);
|
2007-09-27 15:25:55 +02:00
|
|
|
} else {
|
2007-11-09 14:42:56 +01:00
|
|
|
if (strbuf_read_file(&buf, msgfile, 1024) < 0)
|
2011-02-23 00:42:09 +01:00
|
|
|
die_errno(_("could not open or read '%s'"),
|
2009-06-27 17:58:46 +02:00
|
|
|
msgfile);
|
2007-07-20 01:42:28 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-11-09 14:42:56 +01:00
|
|
|
tag = argv[0];
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2007-11-09 14:42:56 +01:00
|
|
|
object_ref = argc == 2 ? argv[1] : "HEAD";
|
|
|
|
if (argc > 2)
|
2021-02-23 22:11:32 +01:00
|
|
|
die(_("too many arguments"));
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2023-03-28 15:58:46 +02:00
|
|
|
if (repo_get_oid(the_repository, object_ref, &object))
|
2011-02-23 00:42:09 +01:00
|
|
|
die(_("Failed to resolve '%s' as a valid ref."), object_ref);
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2011-05-10 01:36:36 +02:00
|
|
|
if (strbuf_check_tag_ref(&ref, tag))
|
2011-02-23 00:42:09 +01:00
|
|
|
die(_("'%s' is not a valid tag name."), tag);
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2017-10-16 00:06:56 +02:00
|
|
|
if (read_ref(ref.buf, &prev))
|
2017-05-07 00:10:08 +02:00
|
|
|
oidclr(&prev);
|
2007-07-20 01:42:28 +02:00
|
|
|
else if (!force)
|
2011-02-23 00:42:09 +01:00
|
|
|
die(_("tag '%s' already exists"), tag);
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2011-12-07 04:01:45 +01:00
|
|
|
opt.message_given = msg.given || msgfile;
|
2018-02-06 09:36:24 +01:00
|
|
|
opt.use_editor = edit_flag;
|
2011-12-07 04:01:45 +01:00
|
|
|
|
|
|
|
if (!cleanup_arg || !strcmp(cleanup_arg, "strip"))
|
|
|
|
opt.cleanup_mode = CLEANUP_ALL;
|
|
|
|
else if (!strcmp(cleanup_arg, "verbatim"))
|
|
|
|
opt.cleanup_mode = CLEANUP_NONE;
|
|
|
|
else if (!strcmp(cleanup_arg, "whitespace"))
|
|
|
|
opt.cleanup_mode = CLEANUP_SPACE;
|
|
|
|
else
|
|
|
|
die(_("Invalid cleanup mode %s"), cleanup_arg);
|
|
|
|
|
2017-05-07 00:10:08 +02:00
|
|
|
create_reflog_msg(&object, &reflog_msg);
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
|
2016-03-22 21:41:26 +01:00
|
|
|
if (create_tag_object) {
|
|
|
|
if (force_sign_annotate && !annotate)
|
|
|
|
opt.sign = 1;
|
2019-04-04 20:25:15 +02:00
|
|
|
create_tag(&object, object_ref, tag, &buf, &opt, &prev, &object);
|
2016-03-22 21:41:26 +01:00
|
|
|
}
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2014-04-17 00:30:41 +02:00
|
|
|
transaction = ref_transaction_begin(&err);
|
|
|
|
if (!transaction ||
|
2017-10-16 00:06:53 +02:00
|
|
|
ref_transaction_update(transaction, ref.buf, &object, &prev,
|
2015-07-21 23:04:55 +02:00
|
|
|
create_reflog ? REF_FORCE_CREATE_REFLOG : 0,
|
tag: generate useful reflog message
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 23:41:18 +01:00
|
|
|
reflog_msg.buf, &err) ||
|
2014-04-30 21:22:42 +02:00
|
|
|
ref_transaction_commit(transaction, &err))
|
2014-04-17 00:30:41 +02:00
|
|
|
die("%s", err.buf);
|
|
|
|
ref_transaction_free(transaction);
|
2018-08-28 23:22:48 +02:00
|
|
|
if (force && !is_null_oid(&prev) && !oideq(&prev, &object))
|
2018-03-12 03:27:30 +01:00
|
|
|
printf(_("Updated tag '%s' (was %s)\n"), tag,
|
2023-03-28 15:58:46 +02:00
|
|
|
repo_find_unique_abbrev(the_repository, &prev, DEFAULT_ABBREV));
|
2007-07-20 01:42:28 +02:00
|
|
|
|
2021-10-20 20:27:19 +02:00
|
|
|
cleanup:
|
2021-10-20 20:27:20 +02:00
|
|
|
ref_sorting_release(sorting);
|
2021-10-20 20:27:19 +02:00
|
|
|
strbuf_release(&buf);
|
|
|
|
strbuf_release(&ref);
|
|
|
|
strbuf_release(&reflog_msg);
|
|
|
|
strbuf_release(&msg.buf);
|
|
|
|
strbuf_release(&err);
|
parse-options: consistently allocate memory in fix_filename()
When handling OPT_FILENAME(), we have to stick the "prefix" (if any) in
front of the filename to make up for the fact that Git has chdir()'d to
the top of the repository. We can do this with prefix_filename(), but
there are a few special cases we handle ourselves.
Unfortunately the memory allocation is inconsistent here; if we do make
it to prefix_filename(), we'll allocate a string which the caller must
free to avoid a leak. But if we hit our special cases, we'll return the
string as-is, and a caller which tries to free it will crash. So there's
no way to win.
Let's consistently allocate, so that callers can do the right thing.
There are now three cases to care about in the function (and hence a
three-armed if/else):
1. we got a NULL input (and should leave it as NULL, though arguably
this is the sign of a bug; let's keep the status quo for now and we
can pick at that scab later)
2. we hit a special case that means we leave the name intact; we
should duplicate the string. This includes our special "-"
matching. Prior to this patch, it also included empty prefixes and
absolute filenames. But we can observe that prefix_filename()
already handles these, so we don't need to detect them.
3. everything else goes to prefix_filename()
I've dropped the "const" from the "char **file" parameter to indicate
that we're allocating, though in practice it's not really important.
This is all being shuffled through a void pointer via opt->value before
it hits code which ever looks at the string. And it's even a bit weird,
because we are really taking _in_ a const string and using the same
out-parameter for a non-const string. A better function signature would
be:
static char *fix_filename(const char *prefix, const char *file);
but that would mean the caller dereferences the double-pointer (and the
NULL check is currently handled inside this function). So I took the
path of least-change here.
Note that we have to fix several callers in this commit, too, or we'll
break the leak-checking tests. These are "new" leaks in the sense that
they are now triggered by the test suite, but these spots have always
been leaky when Git is run in a subdirectory of the repository. I fixed
all of the cases that trigger with GIT_TEST_PASSING_SANITIZE_LEAK. There
may be others in scripts that have other leaks, but we can fix them
later along with those other leaks (and again, you _couldn't_ fix them
before this patch, so this is the necessary first step).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:31:22 +01:00
|
|
|
free(msgfile);
|
2021-10-20 20:27:19 +02:00
|
|
|
return ret;
|
2007-07-20 01:42:28 +02:00
|
|
|
}
|