2007-07-20 03:42:28 +04: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 21:07:36 +03:00
|
|
|
#include "config.h"
|
2007-07-20 03:42:28 +04:00
|
|
|
#include "builtin.h"
|
|
|
|
|
#include "refs.h"
|
2018-05-16 02:42:15 +03:00
|
|
|
#include "object-store.h"
|
2007-07-20 03:42:28 +04:00
|
|
|
#include "tag.h"
|
|
|
|
|
#include "run-command.h"
|
2007-11-09 16:42:56 +03:00
|
|
|
#include "parse-options.h"
|
2011-06-11 23:04:08 +04:00
|
|
|
#include "diff.h"
|
|
|
|
|
#include "revision.h"
|
2011-09-08 08:19:47 +04:00
|
|
|
#include "gpg-interface.h"
|
2012-02-09 03:03:43 +04:00
|
|
|
#include "sha1-array.h"
|
2012-04-13 14:54:41 +04:00
|
|
|
#include "column.h"
|
2015-09-10 18:48:27 +03:00
|
|
|
#include "ref-filter.h"
|
2007-11-09 16:42:56 +03:00
|
|
|
|
|
|
|
|
static const char * const git_tag_usage[] = {
|
2015-01-13 10:44:47 +03:00
|
|
|
N_("git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <tagname> [<head>]"),
|
2012-08-20 16:32:47 +04:00
|
|
|
N_("git tag -d <tagname>..."),
|
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 21:40:57 +03:00
|
|
|
N_("git tag -l [-n[<num>]] [--contains <commit>] [--no-contains <commit>] [--points-at <object>]"
|
2015-09-10 19:22:49 +03:00
|
|
|
"\n\t\t[--format=<format>] [--[no-]merged [<commit>]] [<pattern>...]"),
|
2017-01-18 02:37:21 +03:00
|
|
|
N_("git tag -v [--format=<format>] <tagname>..."),
|
2007-11-09 16:42:56 +03:00
|
|
|
NULL
|
|
|
|
|
};
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2012-04-13 14:54:41 +04:00
|
|
|
static unsigned int colopts;
|
2016-03-22 23:41:26 +03:00
|
|
|
static int force_sign_annotate;
|
2012-02-09 03:03:43 +04:00
|
|
|
|
2017-07-13 18:01:18 +03:00
|
|
|
static int list_tags(struct ref_filter *filter, struct ref_sorting *sorting,
|
|
|
|
|
struct ref_format *format)
|
2012-02-06 12:13:12 +04:00
|
|
|
{
|
2015-09-10 18:48:27 +03:00
|
|
|
struct ref_array array;
|
2015-09-11 18:06:46 +03:00
|
|
|
char *to_free = NULL;
|
2012-02-06 12:13:12 +04:00
|
|
|
int i;
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2015-09-10 18:48:27 +03:00
|
|
|
memset(&array, 0, sizeof(array));
|
2009-01-26 17:13:25 +03:00
|
|
|
|
2015-09-10 18:48:27 +03:00
|
|
|
if (filter->lines == -1)
|
|
|
|
|
filter->lines = 0;
|
2012-02-09 03:03:43 +04:00
|
|
|
|
2017-07-13 18:01:18 +03:00
|
|
|
if (!format->format) {
|
2015-09-11 18:06:46 +03:00
|
|
|
if (filter->lines) {
|
|
|
|
|
to_free = xstrfmt("%s %%(contents:lines=%d)",
|
2017-01-10 11:49:46 +03:00
|
|
|
"%(align:15)%(refname:lstrip=2)%(end)",
|
2015-09-11 18:06:46 +03:00
|
|
|
filter->lines);
|
2017-07-13 18:01:18 +03:00
|
|
|
format->format = to_free;
|
2015-09-11 18:06:46 +03:00
|
|
|
} else
|
2017-07-13 18:01:18 +03:00
|
|
|
format->format = "%(refname:lstrip=2)";
|
2007-07-20 03:42:28 +04:00
|
|
|
}
|
|
|
|
|
|
2017-07-13 17:56:10 +03:00
|
|
|
if (verify_ref_format(format))
|
|
|
|
|
die(_("unable to parse format string"));
|
2015-10-18 13:25:04 +03:00
|
|
|
filter->with_commit_tag_algo = 1;
|
2015-09-11 18:06:16 +03:00
|
|
|
filter_refs(&array, filter, FILTER_REFS_TAGS);
|
|
|
|
|
ref_array_sort(sorting, &array);
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2015-09-11 18:06:16 +03:00
|
|
|
for (i = 0; i < array.nr; i++)
|
2017-07-13 18:01:18 +03:00
|
|
|
show_ref_array_item(array.items[i], format);
|
2015-09-11 18:06:16 +03:00
|
|
|
ref_array_clear(&array);
|
|
|
|
|
free(to_free);
|
2014-02-27 16:56:52 +04:00
|
|
|
|
2007-07-20 03:42:28 +04:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2007-07-21 16:13:12 +04:00
|
|
|
typedef int (*each_tag_name_fn)(const char *name, const char *ref,
|
2017-05-07 01:10:08 +03:00
|
|
|
const struct object_id *oid, const void *cb_data);
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2017-01-18 02:37:21 +03:00
|
|
|
static int for_each_tag_name(const char **argv, each_tag_name_fn fn,
|
|
|
|
|
const void *cb_data)
|
2007-07-20 03:42:28 +04:00
|
|
|
{
|
|
|
|
|
const char **p;
|
2017-03-28 22:46:30 +03:00
|
|
|
struct strbuf ref = STRBUF_INIT;
|
2007-07-20 03:42:28 +04:00
|
|
|
int had_error = 0;
|
2017-05-07 01:10:08 +03:00
|
|
|
struct object_id oid;
|
2007-07-20 03:42:28 +04:00
|
|
|
|
|
|
|
|
for (p = argv; *p; p++) {
|
2017-03-28 22:46:30 +03:00
|
|
|
strbuf_reset(&ref);
|
|
|
|
|
strbuf_addf(&ref, "refs/tags/%s", *p);
|
2017-10-16 01:06:56 +03:00
|
|
|
if (read_ref(ref.buf, &oid)) {
|
2011-02-23 02:42:09 +03:00
|
|
|
error(_("tag '%s' not found."), *p);
|
2007-07-20 03:42:28 +04:00
|
|
|
had_error = 1;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2017-05-07 01:10:08 +03:00
|
|
|
if (fn(*p, ref.buf, &oid, cb_data))
|
2007-07-20 03:42:28 +04:00
|
|
|
had_error = 1;
|
|
|
|
|
}
|
2017-03-28 22:46:30 +03:00
|
|
|
strbuf_release(&ref);
|
2007-07-20 03:42:28 +04:00
|
|
|
return had_error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int delete_tag(const char *name, const char *ref,
|
2017-05-07 01:10:08 +03:00
|
|
|
const struct object_id *oid, const void *cb_data)
|
2007-07-20 03:42:28 +04:00
|
|
|
{
|
2017-10-16 01:06:50 +03:00
|
|
|
if (delete_ref(NULL, ref, oid, 0))
|
2007-07-20 03:42:28 +04:00
|
|
|
return 1;
|
2018-03-12 05:27:30 +03:00
|
|
|
printf(_("Deleted tag '%s' (was %s)\n"), name,
|
|
|
|
|
find_unique_abbrev(oid, DEFAULT_ABBREV));
|
2007-07-20 03:42:28 +04:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int verify_tag(const char *name, const char *ref,
|
2017-05-07 01:10:08 +03:00
|
|
|
const struct object_id *oid, const void *cb_data)
|
2007-07-20 03:42:28 +04:00
|
|
|
{
|
2017-01-18 02:37:21 +03:00
|
|
|
int flags;
|
2017-07-13 18:01:18 +03:00
|
|
|
const struct ref_format *format = cb_data;
|
2017-01-18 02:37:21 +03:00
|
|
|
flags = GPG_VERIFY_VERBOSE;
|
|
|
|
|
|
2017-07-13 18:01:18 +03:00
|
|
|
if (format->format)
|
2017-01-18 02:37:21 +03:00
|
|
|
flags = GPG_VERIFY_OMIT_STATUS;
|
|
|
|
|
|
2017-07-13 03:44:15 +03:00
|
|
|
if (gpg_verify_tag(oid, name, flags))
|
2017-01-18 02:37:21 +03:00
|
|
|
return -1;
|
|
|
|
|
|
2017-07-13 18:01:18 +03:00
|
|
|
if (format->format)
|
2018-04-06 21:58:32 +03:00
|
|
|
pretty_print_ref(name, oid, format);
|
2017-01-18 02:37:21 +03:00
|
|
|
|
|
|
|
|
return 0;
|
2007-07-20 03:42:28 +04:00
|
|
|
}
|
|
|
|
|
|
2007-09-10 14:35:09 +04:00
|
|
|
static int do_sign(struct strbuf *buffer)
|
2007-07-20 03:42:28 +04:00
|
|
|
{
|
2011-09-08 08:19:47 +04:00
|
|
|
return sign_buffer(buffer, buffer, get_signing_key());
|
2007-07-20 03:42:28 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char tag_template[] =
|
2013-08-30 02:03:10 +04:00
|
|
|
N_("\nWrite a message for tag:\n %s\n"
|
2013-01-16 23:18:48 +04:00
|
|
|
"Lines starting with '%c' will be ignored.\n");
|
2011-12-07 07:01:45 +04:00
|
|
|
|
|
|
|
|
static const char tag_template_nocleanup[] =
|
2013-08-30 02:03:10 +04:00
|
|
|
N_("\nWrite a message for tag:\n %s\n"
|
2013-01-16 23:18:48 +04:00
|
|
|
"Lines starting with '%c' will be kept; you may remove them"
|
|
|
|
|
" yourself if you want to.\n");
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2008-05-14 21:46:53 +04:00
|
|
|
static int git_tag_config(const char *var, const char *value, void *cb)
|
2007-07-20 03:42:28 +04:00
|
|
|
{
|
2014-07-17 01:48:02 +04:00
|
|
|
int status;
|
2015-09-11 18:06:16 +03:00
|
|
|
struct ref_sorting **sorting_tail = (struct ref_sorting **)cb;
|
2014-07-17 01:48:02 +04:00
|
|
|
|
|
|
|
|
if (!strcmp(var, "tag.sort")) {
|
|
|
|
|
if (!value)
|
|
|
|
|
return config_error_nonbool(var);
|
2017-07-13 18:02:44 +03:00
|
|
|
parse_ref_sorting(sorting_tail, value);
|
2014-07-17 01:48:02 +04:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
status = git_gpg_config(var, value, cb);
|
2011-09-08 08:19:47 +04:00
|
|
|
if (status)
|
|
|
|
|
return status;
|
2016-03-22 23:41:26 +03:00
|
|
|
if (!strcmp(var, "tag.forcesignannotated")) {
|
|
|
|
|
force_sign_annotate = git_config_bool(var, value);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-01 00:55:40 +04:00
|
|
|
if (starts_with(var, "column."))
|
2012-04-13 14:54:41 +04: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 20:26:02 +03:00
|
|
|
return git_color_default_config(var, value, cb);
|
2007-07-20 03:42:28 +04:00
|
|
|
}
|
|
|
|
|
|
2017-05-07 01:10:08 +03:00
|
|
|
static void write_tag_body(int fd, const struct object_id *oid)
|
2007-11-04 03:11:14 +03:00
|
|
|
{
|
|
|
|
|
unsigned long size;
|
|
|
|
|
enum object_type type;
|
2010-11-10 14:17:28 +03:00
|
|
|
char *buf, *sp;
|
2007-11-04 03:11:14 +03:00
|
|
|
|
sha1_file: convert read_sha1_file to struct object_id
Convert read_sha1_file to take a pointer to struct object_id and rename
it read_object_file. Do the same for read_sha1_file_extended.
Convert one use in grep.c to use the new function without any other code
change, since the pointer being passed is a void pointer that is already
initialized with a pointer to struct object_id. Update the declaration
and definitions of the modified functions, and apply the following
semantic patch to convert the remaining callers:
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1.hash, E2, E3)
+ read_object_file(&E1, E2, E3)
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1->hash, E2, E3)
+ read_object_file(E1, E2, E3)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1.hash, E2, E3, E4)
+ read_object_file_extended(&E1, E2, E3, E4)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1->hash, E2, E3, E4)
+ read_object_file_extended(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 05:27:53 +03:00
|
|
|
buf = read_object_file(oid, &type, &size);
|
2007-11-04 03:11:14 +03:00
|
|
|
if (!buf)
|
|
|
|
|
return;
|
|
|
|
|
/* skip header */
|
|
|
|
|
sp = strstr(buf, "\n\n");
|
|
|
|
|
|
|
|
|
|
if (!sp || !size || type != OBJ_TAG) {
|
|
|
|
|
free(buf);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
sp += 2; /* skip the 2 LFs */
|
2010-11-10 14:17:28 +03:00
|
|
|
write_or_die(fd, sp, parse_signature(sp, buf + size - sp));
|
2007-11-04 03:11:14 +03:00
|
|
|
|
|
|
|
|
free(buf);
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-07 01:10:08 +03:00
|
|
|
static int build_tag_object(struct strbuf *buf, int sign, struct object_id *result)
|
2008-12-06 22:40:34 +03:00
|
|
|
{
|
|
|
|
|
if (sign && do_sign(buf) < 0)
|
2011-02-23 02:42:09 +03:00
|
|
|
return error(_("unable to sign the tag"));
|
2018-01-28 03:13:19 +03:00
|
|
|
if (write_object_file(buf->buf, buf->len, tag_type, result) < 0)
|
2011-02-23 02:42:09 +03:00
|
|
|
return error(_("unable to write tag file"));
|
2008-12-06 22:40:34 +03:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2011-12-07 07:01:45 +04:00
|
|
|
struct create_tag_options {
|
|
|
|
|
unsigned int message_given:1;
|
2018-02-06 11:36:24 +03:00
|
|
|
unsigned int use_editor:1;
|
2011-12-07 07:01:45 +04:00
|
|
|
unsigned int sign;
|
|
|
|
|
enum {
|
|
|
|
|
CLEANUP_NONE,
|
|
|
|
|
CLEANUP_SPACE,
|
|
|
|
|
CLEANUP_ALL
|
|
|
|
|
} cleanup_mode;
|
|
|
|
|
};
|
|
|
|
|
|
2017-05-07 01:10:08 +03:00
|
|
|
static void create_tag(const struct object_id *object, const char *tag,
|
2011-12-07 07:01:45 +04:00
|
|
|
struct strbuf *buf, struct create_tag_options *opt,
|
2017-05-07 01:10:08 +03:00
|
|
|
struct object_id *prev, struct object_id *result)
|
2007-07-20 03:42:28 +04:00
|
|
|
{
|
|
|
|
|
enum object_type type;
|
2017-03-28 22:46:23 +03:00
|
|
|
struct strbuf header = STRBUF_INIT;
|
2008-12-06 22:40:34 +03:00
|
|
|
char *path = NULL;
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2018-04-25 21:20:59 +03:00
|
|
|
type = oid_object_info(the_repository, object, NULL);
|
2007-07-21 16:13:12 +04:00
|
|
|
if (type <= OBJ_NONE)
|
2011-02-23 02:42:09 +03:00
|
|
|
die(_("bad object type."));
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2017-03-28 22:46:23 +03:00
|
|
|
strbuf_addf(&header,
|
|
|
|
|
"object %s\n"
|
|
|
|
|
"type %s\n"
|
|
|
|
|
"tag %s\n"
|
|
|
|
|
"tagger %s\n\n",
|
2017-05-07 01:10:08 +03:00
|
|
|
oid_to_hex(object),
|
2018-02-14 21:59:24 +03:00
|
|
|
type_name(type),
|
2017-03-28 22:46:23 +03:00
|
|
|
tag,
|
|
|
|
|
git_committer_info(IDENT_STRICT));
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2018-02-06 11:36:24 +03:00
|
|
|
if (!opt->message_given || opt->use_editor) {
|
2007-07-20 03:42:28 +04:00
|
|
|
int fd;
|
|
|
|
|
|
|
|
|
|
/* write the template message before editing: */
|
2008-10-27 13:22:09 +03:00
|
|
|
path = git_pathdup("TAG_EDITMSG");
|
2007-07-20 03:42:28 +04:00
|
|
|
fd = open(path, O_CREAT | O_TRUNC | O_WRONLY, 0600);
|
|
|
|
|
if (fd < 0)
|
2011-02-23 02:42:09 +03:00
|
|
|
die_errno(_("could not create file '%s'"), path);
|
2007-11-04 03:11:14 +03:00
|
|
|
|
2018-02-06 11:36:24 +03: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 03:11:14 +03:00
|
|
|
write_tag_body(fd, prev);
|
2013-01-16 23:18:48 +04:00
|
|
|
} else {
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
strbuf_addch(&buf, '\n');
|
|
|
|
|
if (opt->cleanup_mode == CLEANUP_ALL)
|
2013-08-30 02:03:10 +04:00
|
|
|
strbuf_commented_addf(&buf, _(tag_template), tag, comment_line_char);
|
2013-01-16 23:18:48 +04:00
|
|
|
else
|
2013-08-30 02:03:10 +04:00
|
|
|
strbuf_commented_addf(&buf, _(tag_template_nocleanup), tag, comment_line_char);
|
2013-01-16 23:18:48 +04:00
|
|
|
write_or_die(fd, buf.buf, buf.len);
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
}
|
2007-07-20 03:42:28 +04:00
|
|
|
close(fd);
|
|
|
|
|
|
2008-07-25 20:28:42 +04:00
|
|
|
if (launch_editor(path, buf, NULL)) {
|
|
|
|
|
fprintf(stderr,
|
2011-02-23 02:42:09 +03:00
|
|
|
_("Please supply the message using either -m or -F option.\n"));
|
2008-07-25 20:28:42 +04:00
|
|
|
exit(1);
|
|
|
|
|
}
|
2007-07-20 03:42:28 +04:00
|
|
|
}
|
|
|
|
|
|
2011-12-07 07:01:45 +04:00
|
|
|
if (opt->cleanup_mode != CLEANUP_NONE)
|
2015-10-16 18:16:42 +03:00
|
|
|
strbuf_stripspace(buf, opt->cleanup_mode == CLEANUP_ALL);
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2011-12-07 07:01:45 +04:00
|
|
|
if (!opt->message_given && !buf->len)
|
2011-02-23 02:42:09 +03:00
|
|
|
die(_("no tag message?"));
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2017-03-28 22:46:23 +03:00
|
|
|
strbuf_insert(buf, 0, header.buf, header.len);
|
|
|
|
|
strbuf_release(&header);
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2011-12-07 07:01:45 +04:00
|
|
|
if (build_tag_object(buf, opt->sign, result) < 0) {
|
2008-12-06 22:40:34 +03:00
|
|
|
if (path)
|
2011-02-23 02:42:09 +03:00
|
|
|
fprintf(stderr, _("The tag message has been left in %s\n"),
|
2008-12-06 22:40:34 +03:00
|
|
|
path);
|
|
|
|
|
exit(128);
|
|
|
|
|
}
|
|
|
|
|
if (path) {
|
2009-04-30 01:22:56 +04:00
|
|
|
unlink_or_warn(path);
|
2008-12-06 22:40:34 +03:00
|
|
|
free(path);
|
|
|
|
|
}
|
2007-07-20 03:42:28 +04:00
|
|
|
}
|
|
|
|
|
|
2017-05-07 01:10:08 +03: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-09 01:41:18 +03: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-05-01 00:32:47 +03: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 05:27:28 +03: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-09 01:41:18 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
strbuf_addstr(sb, " (");
|
2018-04-25 21:20:59 +03: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-09 01:41:18 +03:00
|
|
|
switch (type) {
|
|
|
|
|
default:
|
2017-05-01 00:32:47 +03: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-09 01:41:18 +03:00
|
|
|
break;
|
|
|
|
|
case OBJ_COMMIT:
|
sha1_file: convert read_sha1_file to struct object_id
Convert read_sha1_file to take a pointer to struct object_id and rename
it read_object_file. Do the same for read_sha1_file_extended.
Convert one use in grep.c to use the new function without any other code
change, since the pointer being passed is a void pointer that is already
initialized with a pointer to struct object_id. Update the declaration
and definitions of the modified functions, and apply the following
semantic patch to convert the remaining callers:
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1.hash, E2, E3)
+ read_object_file(&E1, E2, E3)
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1->hash, E2, E3)
+ read_object_file(E1, E2, E3)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1.hash, E2, E3, E4)
+ read_object_file_extended(&E1, E2, E3, E4)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1->hash, E2, E3, E4)
+ read_object_file_extended(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 05:27:53 +03:00
|
|
|
if ((buf = read_object_file(oid, &type, &size)) != 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-09 01:41:18 +03:00
|
|
|
subject_len = find_commit_subject(buf, &subject_start);
|
|
|
|
|
strbuf_insert(sb, sb->len, subject_start, subject_len);
|
|
|
|
|
} else {
|
2017-05-01 00:32:47 +03: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-09 01:41:18 +03:00
|
|
|
}
|
|
|
|
|
free(buf);
|
|
|
|
|
|
2018-06-29 04:21:58 +03:00
|
|
|
if ((c = lookup_commit_reference(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-09 01:41:18 +03:00
|
|
|
strbuf_addf(sb, ", %s", show_date(c->date, 0, DATE_MODE(SHORT)));
|
|
|
|
|
break;
|
|
|
|
|
case OBJ_TREE:
|
2017-05-01 00:32:47 +03: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-09 01:41:18 +03:00
|
|
|
break;
|
|
|
|
|
case OBJ_BLOB:
|
2017-05-01 00:32:47 +03: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-09 01:41:18 +03:00
|
|
|
break;
|
|
|
|
|
case OBJ_TAG:
|
2017-05-01 00:32:47 +03: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-09 01:41:18 +03:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
strbuf_addch(sb, ')');
|
|
|
|
|
}
|
|
|
|
|
|
2007-11-23 10:16:51 +03: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;
|
|
|
|
|
|
|
|
|
|
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 03:36:36 +04:00
|
|
|
static int strbuf_check_tag_ref(struct strbuf *sb, const char *name)
|
|
|
|
|
{
|
|
|
|
|
if (name[0] == '-')
|
2011-09-16 01:10:25 +04:00
|
|
|
return -1;
|
2011-05-10 03:36:36 +04:00
|
|
|
|
|
|
|
|
strbuf_reset(sb);
|
|
|
|
|
strbuf_addf(sb, "refs/tags/%s", name);
|
|
|
|
|
|
2011-09-16 01:10:25 +04:00
|
|
|
return check_refname_format(sb->buf, 0);
|
2011-05-10 03:36:36 +04:00
|
|
|
}
|
|
|
|
|
|
2007-07-20 03:42:28 +04:00
|
|
|
int cmd_tag(int argc, const char **argv, const char *prefix)
|
|
|
|
|
{
|
2008-10-09 23:12:12 +04:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2011-05-10 03:36:36 +04: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-09 01:41:18 +03:00
|
|
|
struct strbuf reflog_msg = STRBUF_INIT;
|
2017-05-07 01:10:08 +03:00
|
|
|
struct object_id object, prev;
|
2007-07-20 03:42:28 +04:00
|
|
|
const char *object_ref, *tag;
|
2011-12-07 07:01:45 +04:00
|
|
|
struct create_tag_options opt;
|
|
|
|
|
char *cleanup_arg = NULL;
|
2015-07-22 00:04:55 +03:00
|
|
|
int create_reflog = 0;
|
2015-09-10 18:48:27 +03:00
|
|
|
int annotate = 0, force = 0;
|
2016-03-22 23:41:26 +03:00
|
|
|
int cmdmode = 0, create_tag_object = 0;
|
2008-08-06 22:43:47 +04:00
|
|
|
const char *msgfile = NULL, *keyid = NULL;
|
2007-11-23 10:16:51 +03:00
|
|
|
struct msg_arg msg = { 0, STRBUF_INIT };
|
2014-04-17 02:30:41 +04:00
|
|
|
struct ref_transaction *transaction;
|
|
|
|
|
struct strbuf err = STRBUF_INIT;
|
2015-09-10 18:48:27 +03:00
|
|
|
struct ref_filter filter;
|
2015-09-11 18:06:16 +03:00
|
|
|
static struct ref_sorting *sorting = NULL, **sorting_tail = &sorting;
|
2017-07-13 18:01:18 +03:00
|
|
|
struct ref_format format = REF_FORMAT_INIT;
|
2016-12-04 05:52:25 +03:00
|
|
|
int icase = 0;
|
2018-02-06 11:36:24 +03:00
|
|
|
int edit_flag = 0;
|
2007-11-09 16:42:56 +03:00
|
|
|
struct option options[] = {
|
2013-07-30 23:31:27 +04:00
|
|
|
OPT_CMDMODE('l', "list", &cmdmode, N_("list tag names"), 'l'),
|
2015-09-10 18:48:27 +03:00
|
|
|
{ OPTION_INTEGER, 'n', NULL, &filter.lines, N_("n"),
|
2012-08-20 16:32:47 +04:00
|
|
|
N_("print <n> lines of each tag message"),
|
2007-11-09 16:42:56 +03:00
|
|
|
PARSE_OPT_OPTARG, NULL, 1 },
|
2013-07-30 23:31:27 +04:00
|
|
|
OPT_CMDMODE('d', "delete", &cmdmode, N_("delete tags"), 'd'),
|
|
|
|
|
OPT_CMDMODE('v', "verify", &cmdmode, N_("verify tags"), 'v'),
|
2007-11-09 16:42:56 +03:00
|
|
|
|
2012-08-20 16:32:47 +04:00
|
|
|
OPT_GROUP(N_("Tag creation options")),
|
2013-08-03 15:51:19 +04:00
|
|
|
OPT_BOOL('a', "annotate", &annotate,
|
2012-08-20 16:32:47 +04:00
|
|
|
N_("annotated tag, needs a message")),
|
|
|
|
|
OPT_CALLBACK('m', "message", &msg, N_("message"),
|
|
|
|
|
N_("tag message"), parse_msg_arg),
|
|
|
|
|
OPT_FILENAME('F', "file", &msgfile, N_("read message from file")),
|
2018-02-06 11:36:24 +03:00
|
|
|
OPT_BOOL('e', "edit", &edit_flag, N_("force edit of tag message")),
|
2013-08-03 15:51:19 +04:00
|
|
|
OPT_BOOL('s', "sign", &opt.sign, N_("annotated and GPG-signed tag")),
|
2012-08-20 16:32:47 +04:00
|
|
|
OPT_STRING(0, "cleanup", &cleanup_arg, N_("mode"),
|
|
|
|
|
N_("how to strip spaces and #comments from message")),
|
2014-03-24 02:58:12 +04:00
|
|
|
OPT_STRING('u', "local-user", &keyid, N_("key-id"),
|
2012-08-20 16:32:47 +04:00
|
|
|
N_("use another key to sign the tag")),
|
2018-02-09 14:01:42 +03:00
|
|
|
OPT__FORCE(&force, N_("replace the tag if exists"), 0),
|
2015-09-11 19:04:13 +03:00
|
|
|
OPT_BOOL(0, "create-reflog", &create_reflog, N_("create a reflog")),
|
2015-03-12 21:15:09 +03:00
|
|
|
|
|
|
|
|
OPT_GROUP(N_("Tag listing options")),
|
2012-08-20 16:32:47 +04:00
|
|
|
OPT_COLUMN(0, "column", &colopts, N_("show tag list in columns")),
|
2015-09-10 18:48:27 +03: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 21:40:57 +03:00
|
|
|
OPT_NO_CONTAINS(&filter.no_commit, N_("print only tags that don't contain the commit")),
|
2015-09-10 18:48:27 +03: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 21:40:57 +03:00
|
|
|
OPT_WITHOUT(&filter.no_commit, N_("print only tags that don't contain the commit")),
|
2015-09-10 19:22:49 +03:00
|
|
|
OPT_MERGED(&filter, N_("print only tags that are merged")),
|
|
|
|
|
OPT_NO_MERGED(&filter, N_("print only tags that are not merged")),
|
2015-09-11 18:06:16 +03:00
|
|
|
OPT_CALLBACK(0 , "sort", sorting_tail, N_("key"),
|
|
|
|
|
N_("field name to sort on"), &parse_opt_ref_sorting),
|
2009-01-26 17:13:25 +03:00
|
|
|
{
|
2015-09-10 18:48:27 +03:00
|
|
|
OPTION_CALLBACK, 0, "points-at", &filter.points_at, N_("object"),
|
2017-03-24 21:40:56 +03:00
|
|
|
N_("print only tags of the object"), PARSE_OPT_LASTARG_DEFAULT,
|
|
|
|
|
parse_opt_object_name, (intptr_t) "HEAD"
|
2012-02-09 03:03:43 +04:00
|
|
|
},
|
2017-07-13 18:01:18 +03:00
|
|
|
OPT_STRING( 0 , "format", &format.format, N_("format"),
|
|
|
|
|
N_("format to use for the output")),
|
2017-10-03 16:45:47 +03:00
|
|
|
OPT__COLOR(&format.use_color, N_("respect format colors")),
|
2016-12-04 05:52:25 +03:00
|
|
|
OPT_BOOL('i', "ignore-case", &icase, N_("sorting and filtering are case insensitive")),
|
2007-11-09 16:42:56 +03:00
|
|
|
OPT_END()
|
|
|
|
|
};
|
|
|
|
|
|
2017-01-10 11:49:51 +03:00
|
|
|
setup_ref_filter_porcelain_msg();
|
|
|
|
|
|
2015-09-11 18:06:16 +03:00
|
|
|
git_config(git_tag_config, sorting_tail);
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2011-12-07 07:01:45 +04:00
|
|
|
memset(&opt, 0, sizeof(opt));
|
2015-09-10 18:48:27 +03:00
|
|
|
memset(&filter, 0, sizeof(filter));
|
|
|
|
|
filter.lines = -1;
|
2011-12-07 07:01:45 +04:00
|
|
|
|
2009-05-23 22:53:12 +04:00
|
|
|
argc = parse_options(argc, argv, prefix, options, git_tag_usage, 0);
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2007-12-11 07:08:06 +03:00
|
|
|
if (keyid) {
|
2011-12-07 07:01:45 +04:00
|
|
|
opt.sign = 1;
|
2011-09-08 08:19:47 +04:00
|
|
|
set_signing_key(keyid);
|
2007-12-11 07:08:06 +03:00
|
|
|
}
|
2016-03-22 23:41:26 +03:00
|
|
|
create_tag_object = (opt.sign || annotate || msg.given || msgfile);
|
|
|
|
|
|
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 21:40:55 +03: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 21:40:57 +03:00
|
|
|
else if (filter.with_commit || filter.no_commit ||
|
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 21:40:55 +03:00
|
|
|
filter.points_at.nr || filter.merge_commit ||
|
|
|
|
|
filter.lines != -1)
|
|
|
|
|
cmdmode = 'l';
|
|
|
|
|
}
|
2007-11-26 02:21:42 +03:00
|
|
|
|
2017-08-02 22:40:53 +03:00
|
|
|
if (cmdmode == 'l')
|
2017-08-02 22:40:54 +03:00
|
|
|
setup_auto_pager("tag", 1);
|
2017-08-02 22:40:53 +03:00
|
|
|
|
2016-03-22 23:41:26 +03:00
|
|
|
if ((create_tag_object || force) && (cmdmode != 0))
|
2008-11-05 02:20:31 +03:00
|
|
|
usage_with_options(git_tag_usage, options);
|
|
|
|
|
|
2012-04-13 14:54:41 +04:00
|
|
|
finalize_colopts(&colopts, -1);
|
2015-09-10 18:48:27 +03:00
|
|
|
if (cmdmode == 'l' && filter.lines != -1) {
|
2012-04-13 14:54:41 +04:00
|
|
|
if (explicitly_enable_column(colopts))
|
|
|
|
|
die(_("--column and -n are incompatible"));
|
|
|
|
|
colopts = 0;
|
|
|
|
|
}
|
2015-09-11 18:06:16 +03:00
|
|
|
if (!sorting)
|
|
|
|
|
sorting = ref_default_sorting();
|
2016-12-04 05:52:25 +03:00
|
|
|
sorting->ignore_case = icase;
|
|
|
|
|
filter.ignore_case = icase;
|
2013-07-30 23:31:27 +04:00
|
|
|
if (cmdmode == 'l') {
|
2012-04-13 14:54:41 +04:00
|
|
|
int ret;
|
|
|
|
|
if (column_active(colopts)) {
|
|
|
|
|
struct column_options copts;
|
|
|
|
|
memset(&copts, 0, sizeof(copts));
|
|
|
|
|
copts.padding = 2;
|
|
|
|
|
run_column_filter(colopts, &copts);
|
|
|
|
|
}
|
2015-09-10 18:48:27 +03:00
|
|
|
filter.name_patterns = argv;
|
2017-07-13 18:01:18 +03:00
|
|
|
ret = list_tags(&filter, sorting, &format);
|
2012-04-13 14:54:41 +04:00
|
|
|
if (column_active(colopts))
|
|
|
|
|
stop_column_filter();
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
2015-09-10 18:48:27 +03:00
|
|
|
if (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 21:40:55 +03:00
|
|
|
die(_("-n option is only allowed in list mode"));
|
2015-09-10 18:48:27 +03:00
|
|
|
if (filter.with_commit)
|
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 21:40:55 +03:00
|
|
|
die(_("--contains option is only allowed in list mode"));
|
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 21:40:57 +03:00
|
|
|
if (filter.no_commit)
|
|
|
|
|
die(_("--no-contains option is only allowed in list mode"));
|
2015-09-10 18:48:27 +03:00
|
|
|
if (filter.points_at.nr)
|
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 21:40:55 +03:00
|
|
|
die(_("--points-at option is only allowed in list mode"));
|
2015-09-10 19:22:49 +03:00
|
|
|
if (filter.merge_commit)
|
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 21:40:55 +03:00
|
|
|
die(_("--merged and --no-merged options are only allowed in list mode"));
|
2013-07-30 23:31:27 +04:00
|
|
|
if (cmdmode == 'd')
|
2017-01-18 02:37:21 +03:00
|
|
|
return for_each_tag_name(argv, delete_tag, NULL);
|
|
|
|
|
if (cmdmode == 'v') {
|
2017-07-13 18:01:18 +03:00
|
|
|
if (format.format && verify_ref_format(&format))
|
2017-07-13 17:56:10 +03:00
|
|
|
usage_with_options(git_tag_usage, options);
|
2017-07-13 18:01:18 +03:00
|
|
|
return for_each_tag_name(argv, verify_tag, &format);
|
2017-01-18 02:37:21 +03:00
|
|
|
}
|
2007-11-09 16:42:56 +03:00
|
|
|
|
2007-11-23 10:16:51 +03:00
|
|
|
if (msg.given || msgfile) {
|
|
|
|
|
if (msg.given && msgfile)
|
2011-02-23 02:42:09 +03:00
|
|
|
die(_("only one -F or -m option is allowed."));
|
2007-11-23 10:16:51 +03:00
|
|
|
if (msg.given)
|
|
|
|
|
strbuf_addbuf(&buf, &(msg.buf));
|
2007-11-09 16:42:56 +03:00
|
|
|
else {
|
|
|
|
|
if (!strcmp(msgfile, "-")) {
|
2007-09-27 17:25:55 +04:00
|
|
|
if (strbuf_read(&buf, 0, 1024) < 0)
|
2011-02-23 02:42:09 +03:00
|
|
|
die_errno(_("cannot read '%s'"), msgfile);
|
2007-09-27 17:25:55 +04:00
|
|
|
} else {
|
2007-11-09 16:42:56 +03:00
|
|
|
if (strbuf_read_file(&buf, msgfile, 1024) < 0)
|
2011-02-23 02:42:09 +03:00
|
|
|
die_errno(_("could not open or read '%s'"),
|
2009-06-27 19:58:46 +04:00
|
|
|
msgfile);
|
2007-07-20 03:42:28 +04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2007-11-09 16:42:56 +03:00
|
|
|
tag = argv[0];
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2007-11-09 16:42:56 +03:00
|
|
|
object_ref = argc == 2 ? argv[1] : "HEAD";
|
|
|
|
|
if (argc > 2)
|
2011-02-23 02:42:09 +03:00
|
|
|
die(_("too many params"));
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2017-05-07 01:10:08 +03:00
|
|
|
if (get_oid(object_ref, &object))
|
2011-02-23 02:42:09 +03:00
|
|
|
die(_("Failed to resolve '%s' as a valid ref."), object_ref);
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2011-05-10 03:36:36 +04:00
|
|
|
if (strbuf_check_tag_ref(&ref, tag))
|
2011-02-23 02:42:09 +03:00
|
|
|
die(_("'%s' is not a valid tag name."), tag);
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2017-10-16 01:06:56 +03:00
|
|
|
if (read_ref(ref.buf, &prev))
|
2017-05-07 01:10:08 +03:00
|
|
|
oidclr(&prev);
|
2007-07-20 03:42:28 +04:00
|
|
|
else if (!force)
|
2011-02-23 02:42:09 +03:00
|
|
|
die(_("tag '%s' already exists"), tag);
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2011-12-07 07:01:45 +04:00
|
|
|
opt.message_given = msg.given || msgfile;
|
2018-02-06 11:36:24 +03:00
|
|
|
opt.use_editor = edit_flag;
|
2011-12-07 07:01:45 +04: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 01:10:08 +03: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-09 01:41:18 +03:00
|
|
|
|
2016-03-22 23:41:26 +03:00
|
|
|
if (create_tag_object) {
|
|
|
|
|
if (force_sign_annotate && !annotate)
|
|
|
|
|
opt.sign = 1;
|
2017-05-07 01:10:08 +03:00
|
|
|
create_tag(&object, tag, &buf, &opt, &prev, &object);
|
2016-03-22 23:41:26 +03:00
|
|
|
}
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2014-04-17 02:30:41 +04:00
|
|
|
transaction = ref_transaction_begin(&err);
|
|
|
|
|
if (!transaction ||
|
2017-10-16 01:06:53 +03:00
|
|
|
ref_transaction_update(transaction, ref.buf, &object, &prev,
|
2015-07-22 00:04:55 +03: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-09 01:41:18 +03:00
|
|
|
reflog_msg.buf, &err) ||
|
2014-04-30 23:22:42 +04:00
|
|
|
ref_transaction_commit(transaction, &err))
|
2014-04-17 02:30:41 +04:00
|
|
|
die("%s", err.buf);
|
|
|
|
|
ref_transaction_free(transaction);
|
2017-05-07 01:10:08 +03:00
|
|
|
if (force && !is_null_oid(&prev) && oidcmp(&prev, &object))
|
2018-03-12 05:27:30 +03:00
|
|
|
printf(_("Updated tag '%s' (was %s)\n"), tag,
|
|
|
|
|
find_unique_abbrev(&prev, DEFAULT_ABBREV));
|
2007-07-20 03:42:28 +04:00
|
|
|
|
2017-10-01 20:42:08 +03:00
|
|
|
UNLEAK(buf);
|
|
|
|
|
UNLEAK(ref);
|
|
|
|
|
UNLEAK(reflog_msg);
|
|
|
|
|
UNLEAK(msg);
|
|
|
|
|
UNLEAK(err);
|
2007-07-20 03:42:28 +04:00
|
|
|
return 0;
|
|
|
|
|
}
|
