2006-08-03 15:24:38 +00:00
|
|
|
#include "builtin.h"
|
2017-06-14 18:07:36 +00:00
|
|
|
#include "config.h"
|
2005-09-30 21:26:57 +00:00
|
|
|
#include "cache.h"
|
2006-09-21 05:02:01 +00:00
|
|
|
#include "refs.h"
|
2007-10-07 21:18:23 +00:00
|
|
|
#include "parse-options.h"
|
2005-09-30 21:26:57 +00:00
|
|
|
|
2007-10-07 21:18:23 +00:00
|
|
|
static const char * const git_symbolic_ref_usage[] = {
|
2015-01-13 07:44:47 +00:00
|
|
|
N_("git symbolic-ref [<options>] <name> [<ref>]"),
|
symbolic-ref: teach "--[no-]recurse" option
Suppose you are managing many maintenance tracks in your project,
and some of the more recent ones are maint-2.36 and maint-2.37.
Further imagine that your project recently tagged the official 2.38
release, which means you would need to start maint-2.38 track soon,
by doing:
$ git checkout -b maint-2.38 v2.38.0^0
$ git branch --list 'maint-2.3[6-9]'
* maint-2.38
maint-2.36
maint-2.37
So far, so good. But it also is reasonable to want not to have to
worry about which maintenance track is the latest, by pointing a
more generic-sounding 'maint' branch at it, by doing:
$ git symbolic-ref refs/heads/maint refs/heads/maint-2.38
which would allow you to say "whichever it is, check out the latest
maintenance track", by doing:
$ git checkout maint
$ git branch --show-current
maint-2.38
It is arguably better to say that we are on 'maint-2.38' rather than
on 'maint', and "git merge/pull" would record "into maint-2.38" and
not "into maint", so I think what we have is a good behaviour.
One thing that is slightly irritating, however, is that I do not
think there is a good way (other than "cat .git/HEAD") to learn that
you checked out 'maint' to get into that state. Just like the output
of "git branch --show-current" shows above, "git symbolic-ref HEAD"
would report 'refs/heads/maint-2.38', bypassing the intermediate
symbolic ref at 'refs/heads/maint' that is pointed at by HEAD.
The internal resolve_ref() API already has the necessary support for
stopping after resolving a single level of a symbolic-ref, and we
can expose it by adding a "--[no-]recurse" option to the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-07 22:00:39 +00:00
|
|
|
N_("git symbolic-ref -d [-q] [--no-recurse] <name>"),
|
2007-10-07 21:18:23 +00:00
|
|
|
NULL
|
|
|
|
};
|
2005-09-30 21:26:57 +00:00
|
|
|
|
symbolic-ref: teach "--[no-]recurse" option
Suppose you are managing many maintenance tracks in your project,
and some of the more recent ones are maint-2.36 and maint-2.37.
Further imagine that your project recently tagged the official 2.38
release, which means you would need to start maint-2.38 track soon,
by doing:
$ git checkout -b maint-2.38 v2.38.0^0
$ git branch --list 'maint-2.3[6-9]'
* maint-2.38
maint-2.36
maint-2.37
So far, so good. But it also is reasonable to want not to have to
worry about which maintenance track is the latest, by pointing a
more generic-sounding 'maint' branch at it, by doing:
$ git symbolic-ref refs/heads/maint refs/heads/maint-2.38
which would allow you to say "whichever it is, check out the latest
maintenance track", by doing:
$ git checkout maint
$ git branch --show-current
maint-2.38
It is arguably better to say that we are on 'maint-2.38' rather than
on 'maint', and "git merge/pull" would record "into maint-2.38" and
not "into maint", so I think what we have is a good behaviour.
One thing that is slightly irritating, however, is that I do not
think there is a good way (other than "cat .git/HEAD") to learn that
you checked out 'maint' to get into that state. Just like the output
of "git branch --show-current" shows above, "git symbolic-ref HEAD"
would report 'refs/heads/maint-2.38', bypassing the intermediate
symbolic ref at 'refs/heads/maint' that is pointed at by HEAD.
The internal resolve_ref() API already has the necessary support for
stopping after resolving a single level of a symbolic-ref, and we
can expose it by adding a "--[no-]recurse" option to the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-07 22:00:39 +00:00
|
|
|
static int check_symref(const char *HEAD, int quiet, int shorten, int recurse, int print)
|
2005-09-30 21:26:57 +00:00
|
|
|
{
|
symbolic-ref: teach "--[no-]recurse" option
Suppose you are managing many maintenance tracks in your project,
and some of the more recent ones are maint-2.36 and maint-2.37.
Further imagine that your project recently tagged the official 2.38
release, which means you would need to start maint-2.38 track soon,
by doing:
$ git checkout -b maint-2.38 v2.38.0^0
$ git branch --list 'maint-2.3[6-9]'
* maint-2.38
maint-2.36
maint-2.37
So far, so good. But it also is reasonable to want not to have to
worry about which maintenance track is the latest, by pointing a
more generic-sounding 'maint' branch at it, by doing:
$ git symbolic-ref refs/heads/maint refs/heads/maint-2.38
which would allow you to say "whichever it is, check out the latest
maintenance track", by doing:
$ git checkout maint
$ git branch --show-current
maint-2.38
It is arguably better to say that we are on 'maint-2.38' rather than
on 'maint', and "git merge/pull" would record "into maint-2.38" and
not "into maint", so I think what we have is a good behaviour.
One thing that is slightly irritating, however, is that I do not
think there is a good way (other than "cat .git/HEAD") to learn that
you checked out 'maint' to get into that state. Just like the output
of "git branch --show-current" shows above, "git symbolic-ref HEAD"
would report 'refs/heads/maint-2.38', bypassing the intermediate
symbolic ref at 'refs/heads/maint' that is pointed at by HEAD.
The internal resolve_ref() API already has the necessary support for
stopping after resolving a single level of a symbolic-ref, and we
can expose it by adding a "--[no-]recurse" option to the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-07 22:00:39 +00:00
|
|
|
int resolve_flags, flag;
|
|
|
|
const char *refname;
|
|
|
|
|
|
|
|
resolve_flags = (recurse ? 0 : RESOLVE_REF_NO_RECURSE);
|
|
|
|
refname = resolve_ref_unsafe(HEAD, resolve_flags, NULL, &flag);
|
2006-09-12 03:17:35 +00:00
|
|
|
|
2012-02-27 22:10:38 +00:00
|
|
|
if (!refname)
|
2005-09-30 21:26:57 +00:00
|
|
|
die("No such ref: %s", HEAD);
|
2007-01-15 21:56:05 +00:00
|
|
|
else if (!(flag & REF_ISSYMREF)) {
|
|
|
|
if (!quiet)
|
|
|
|
die("ref %s is not a symbolic ref", HEAD);
|
|
|
|
else
|
2012-10-21 11:32:33 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
if (print) {
|
2021-03-14 18:47:34 +00:00
|
|
|
char *to_free = NULL;
|
2012-10-21 11:32:33 +00:00
|
|
|
if (shorten)
|
2021-03-14 18:47:34 +00:00
|
|
|
refname = to_free = shorten_unambiguous_ref(refname, 0);
|
2012-10-21 11:32:33 +00:00
|
|
|
puts(refname);
|
2021-03-14 18:47:34 +00:00
|
|
|
free(to_free);
|
2007-01-15 21:56:05 +00:00
|
|
|
}
|
2012-10-21 11:32:33 +00:00
|
|
|
return 0;
|
2005-09-30 21:26:57 +00:00
|
|
|
}
|
|
|
|
|
2006-08-03 15:24:38 +00:00
|
|
|
int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)
|
2005-09-30 21:26:57 +00:00
|
|
|
{
|
symbolic-ref: teach "--[no-]recurse" option
Suppose you are managing many maintenance tracks in your project,
and some of the more recent ones are maint-2.36 and maint-2.37.
Further imagine that your project recently tagged the official 2.38
release, which means you would need to start maint-2.38 track soon,
by doing:
$ git checkout -b maint-2.38 v2.38.0^0
$ git branch --list 'maint-2.3[6-9]'
* maint-2.38
maint-2.36
maint-2.37
So far, so good. But it also is reasonable to want not to have to
worry about which maintenance track is the latest, by pointing a
more generic-sounding 'maint' branch at it, by doing:
$ git symbolic-ref refs/heads/maint refs/heads/maint-2.38
which would allow you to say "whichever it is, check out the latest
maintenance track", by doing:
$ git checkout maint
$ git branch --show-current
maint-2.38
It is arguably better to say that we are on 'maint-2.38' rather than
on 'maint', and "git merge/pull" would record "into maint-2.38" and
not "into maint", so I think what we have is a good behaviour.
One thing that is slightly irritating, however, is that I do not
think there is a good way (other than "cat .git/HEAD") to learn that
you checked out 'maint' to get into that state. Just like the output
of "git branch --show-current" shows above, "git symbolic-ref HEAD"
would report 'refs/heads/maint-2.38', bypassing the intermediate
symbolic ref at 'refs/heads/maint' that is pointed at by HEAD.
The internal resolve_ref() API already has the necessary support for
stopping after resolving a single level of a symbolic-ref, and we
can expose it by adding a "--[no-]recurse" option to the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-07 22:00:39 +00:00
|
|
|
int quiet = 0, delete = 0, shorten = 0, recurse = 1, ret = 0;
|
2007-01-26 22:26:10 +00:00
|
|
|
const char *msg = NULL;
|
2007-10-07 21:18:23 +00:00
|
|
|
struct option options[] = {
|
2010-11-08 19:54:48 +00:00
|
|
|
OPT__QUIET(&quiet,
|
2012-08-20 12:32:46 +00:00
|
|
|
N_("suppress error message for non-symbolic (detached) refs")),
|
2012-10-21 11:32:33 +00:00
|
|
|
OPT_BOOL('d', "delete", &delete, N_("delete symbolic ref")),
|
2012-08-20 12:32:46 +00:00
|
|
|
OPT_BOOL(0, "short", &shorten, N_("shorten ref output")),
|
symbolic-ref: teach "--[no-]recurse" option
Suppose you are managing many maintenance tracks in your project,
and some of the more recent ones are maint-2.36 and maint-2.37.
Further imagine that your project recently tagged the official 2.38
release, which means you would need to start maint-2.38 track soon,
by doing:
$ git checkout -b maint-2.38 v2.38.0^0
$ git branch --list 'maint-2.3[6-9]'
* maint-2.38
maint-2.36
maint-2.37
So far, so good. But it also is reasonable to want not to have to
worry about which maintenance track is the latest, by pointing a
more generic-sounding 'maint' branch at it, by doing:
$ git symbolic-ref refs/heads/maint refs/heads/maint-2.38
which would allow you to say "whichever it is, check out the latest
maintenance track", by doing:
$ git checkout maint
$ git branch --show-current
maint-2.38
It is arguably better to say that we are on 'maint-2.38' rather than
on 'maint', and "git merge/pull" would record "into maint-2.38" and
not "into maint", so I think what we have is a good behaviour.
One thing that is slightly irritating, however, is that I do not
think there is a good way (other than "cat .git/HEAD") to learn that
you checked out 'maint' to get into that state. Just like the output
of "git branch --show-current" shows above, "git symbolic-ref HEAD"
would report 'refs/heads/maint-2.38', bypassing the intermediate
symbolic ref at 'refs/heads/maint' that is pointed at by HEAD.
The internal resolve_ref() API already has the necessary support for
stopping after resolving a single level of a symbolic-ref, and we
can expose it by adding a "--[no-]recurse" option to the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-07 22:00:39 +00:00
|
|
|
OPT_BOOL(0, "recurse", &recurse, N_("recursively dereference (default)")),
|
2012-08-20 12:32:46 +00:00
|
|
|
OPT_STRING('m', NULL, &msg, N_("reason"), N_("reason of the update")),
|
2007-10-07 21:18:23 +00:00
|
|
|
OPT_END(),
|
|
|
|
};
|
2007-01-15 21:56:05 +00:00
|
|
|
|
2008-05-14 17:46:53 +00:00
|
|
|
git_config(git_default_config, NULL);
|
2009-05-23 18:53:12 +00:00
|
|
|
argc = parse_options(argc, argv, prefix, options,
|
|
|
|
git_symbolic_ref_usage, 0);
|
2013-10-16 17:26:39 +00:00
|
|
|
if (msg && !*msg)
|
2007-10-07 21:18:23 +00:00
|
|
|
die("Refusing to perform update with empty message");
|
2012-10-21 11:32:33 +00:00
|
|
|
|
|
|
|
if (delete) {
|
|
|
|
if (argc != 1)
|
|
|
|
usage_with_options(git_symbolic_ref_usage, options);
|
symbolic-ref: teach "--[no-]recurse" option
Suppose you are managing many maintenance tracks in your project,
and some of the more recent ones are maint-2.36 and maint-2.37.
Further imagine that your project recently tagged the official 2.38
release, which means you would need to start maint-2.38 track soon,
by doing:
$ git checkout -b maint-2.38 v2.38.0^0
$ git branch --list 'maint-2.3[6-9]'
* maint-2.38
maint-2.36
maint-2.37
So far, so good. But it also is reasonable to want not to have to
worry about which maintenance track is the latest, by pointing a
more generic-sounding 'maint' branch at it, by doing:
$ git symbolic-ref refs/heads/maint refs/heads/maint-2.38
which would allow you to say "whichever it is, check out the latest
maintenance track", by doing:
$ git checkout maint
$ git branch --show-current
maint-2.38
It is arguably better to say that we are on 'maint-2.38' rather than
on 'maint', and "git merge/pull" would record "into maint-2.38" and
not "into maint", so I think what we have is a good behaviour.
One thing that is slightly irritating, however, is that I do not
think there is a good way (other than "cat .git/HEAD") to learn that
you checked out 'maint' to get into that state. Just like the output
of "git branch --show-current" shows above, "git symbolic-ref HEAD"
would report 'refs/heads/maint-2.38', bypassing the intermediate
symbolic ref at 'refs/heads/maint' that is pointed at by HEAD.
The internal resolve_ref() API already has the necessary support for
stopping after resolving a single level of a symbolic-ref, and we
can expose it by adding a "--[no-]recurse" option to the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-07 22:00:39 +00:00
|
|
|
ret = check_symref(argv[0], 1, 0, 0, 0);
|
2012-10-21 11:32:33 +00:00
|
|
|
if (ret)
|
|
|
|
die("Cannot delete %s, not a symbolic ref", argv[0]);
|
2016-09-01 22:38:02 +00:00
|
|
|
if (!strcmp(argv[0], "HEAD"))
|
|
|
|
die("deleting '%s' is not allowed", argv[0]);
|
2017-11-05 08:42:06 +00:00
|
|
|
return delete_ref(NULL, argv[0], NULL, REF_NO_DEREF);
|
2012-10-21 11:32:33 +00:00
|
|
|
}
|
|
|
|
|
2005-09-30 21:26:57 +00:00
|
|
|
switch (argc) {
|
2007-10-07 21:18:23 +00:00
|
|
|
case 1:
|
symbolic-ref: teach "--[no-]recurse" option
Suppose you are managing many maintenance tracks in your project,
and some of the more recent ones are maint-2.36 and maint-2.37.
Further imagine that your project recently tagged the official 2.38
release, which means you would need to start maint-2.38 track soon,
by doing:
$ git checkout -b maint-2.38 v2.38.0^0
$ git branch --list 'maint-2.3[6-9]'
* maint-2.38
maint-2.36
maint-2.37
So far, so good. But it also is reasonable to want not to have to
worry about which maintenance track is the latest, by pointing a
more generic-sounding 'maint' branch at it, by doing:
$ git symbolic-ref refs/heads/maint refs/heads/maint-2.38
which would allow you to say "whichever it is, check out the latest
maintenance track", by doing:
$ git checkout maint
$ git branch --show-current
maint-2.38
It is arguably better to say that we are on 'maint-2.38' rather than
on 'maint', and "git merge/pull" would record "into maint-2.38" and
not "into maint", so I think what we have is a good behaviour.
One thing that is slightly irritating, however, is that I do not
think there is a good way (other than "cat .git/HEAD") to learn that
you checked out 'maint' to get into that state. Just like the output
of "git branch --show-current" shows above, "git symbolic-ref HEAD"
would report 'refs/heads/maint-2.38', bypassing the intermediate
symbolic ref at 'refs/heads/maint' that is pointed at by HEAD.
The internal resolve_ref() API already has the necessary support for
stopping after resolving a single level of a symbolic-ref, and we
can expose it by adding a "--[no-]recurse" option to the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-07 22:00:39 +00:00
|
|
|
ret = check_symref(argv[0], quiet, shorten, recurse, 1);
|
2005-09-30 21:26:57 +00:00
|
|
|
break;
|
2007-10-07 21:18:23 +00:00
|
|
|
case 2:
|
2009-01-29 08:33:02 +00:00
|
|
|
if (!strcmp(argv[0], "HEAD") &&
|
2013-11-30 20:55:40 +00:00
|
|
|
!starts_with(argv[1], "refs/"))
|
2009-02-13 18:26:09 +00:00
|
|
|
die("Refusing to point HEAD outside of refs/");
|
2015-12-20 07:27:18 +00:00
|
|
|
ret = !!create_symref(argv[0], argv[1], msg);
|
2005-09-30 21:26:57 +00:00
|
|
|
break;
|
|
|
|
default:
|
2007-10-07 21:18:23 +00:00
|
|
|
usage_with_options(git_symbolic_ref_usage, options);
|
2005-09-30 21:26:57 +00:00
|
|
|
}
|
2012-10-21 11:32:33 +00:00
|
|
|
return ret;
|
2005-09-30 21:26:57 +00:00
|
|
|
}
|