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