2005-10-04 23:45:01 +00:00
|
|
|
git-symbolic-ref(1)
|
|
|
|
|
===================
|
|
|
|
|
|
|
|
|
|
NAME
|
|
|
|
|
----
|
2012-10-21 11:32:33 +00:00
|
|
|
git-symbolic-ref - Read, modify and delete symbolic refs
|
2005-10-04 23:45:01 +00:00
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
|
--------
|
2011-07-02 02:38:26 +00:00
|
|
|
[verse]
|
2012-02-27 22:10:38 +00:00
|
|
|
'git symbolic-ref' [-m <reason>] <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
|
|
|
'git symbolic-ref' [-q] [--short] [--no-recurse] <name>
|
2012-10-21 11:32:33 +00:00
|
|
|
'git symbolic-ref' --delete [-q] <name>
|
2005-10-04 23:45:01 +00:00
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
|
-----------
|
|
|
|
|
Given one argument, reads which branch head the given symbolic
|
|
|
|
|
ref refers to and outputs its path, relative to the `.git/`
|
|
|
|
|
directory. Typically you would give `HEAD` as the <name>
|
2009-08-11 00:52:07 +00:00
|
|
|
argument to see which branch your working tree is on.
|
2005-10-04 23:45:01 +00:00
|
|
|
|
2009-08-11 00:52:07 +00:00
|
|
|
Given two arguments, creates or updates a symbolic ref <name> to
|
2005-10-04 23:45:01 +00:00
|
|
|
point at the given branch <ref>.
|
|
|
|
|
|
2012-10-21 11:32:33 +00:00
|
|
|
Given `--delete` and an additional argument, deletes the given
|
|
|
|
|
symbolic ref.
|
|
|
|
|
|
2006-11-30 10:50:28 +00:00
|
|
|
A symbolic ref is a regular file that stores a string that
|
|
|
|
|
begins with `ref: refs/`. For example, your `.git/HEAD` is
|
2023-10-08 06:45:09 +00:00
|
|
|
a regular file whose content is `ref: refs/heads/master`.
|
2006-11-30 10:50:28 +00:00
|
|
|
|
2007-01-15 21:56:05 +00:00
|
|
|
OPTIONS
|
|
|
|
|
-------
|
|
|
|
|
|
2012-10-21 11:32:33 +00:00
|
|
|
-d::
|
|
|
|
|
--delete::
|
|
|
|
|
Delete the symbolic ref <name>.
|
|
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-q::
|
|
|
|
|
--quiet::
|
2007-01-15 21:56:05 +00:00
|
|
|
Do not issue an error message if the <name> is not a
|
|
|
|
|
symbolic ref but a detached HEAD; instead exit with
|
|
|
|
|
non-zero status silently.
|
|
|
|
|
|
2012-02-27 22:10:38 +00:00
|
|
|
--short::
|
|
|
|
|
When showing the value of <name> as a symbolic ref, try to shorten the
|
|
|
|
|
value, e.g. from `refs/heads/master` to `master`.
|
|
|
|
|
|
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
|
|
|
--recurse::
|
|
|
|
|
--no-recurse::
|
|
|
|
|
When showing the value of <name> as a symbolic ref, if
|
|
|
|
|
<name> refers to another symbolic ref, follow such a chain
|
|
|
|
|
of symbolic refs until the result no longer points at a
|
|
|
|
|
symbolic ref (`--recurse`, which is the default).
|
|
|
|
|
`--no-recurse` stops after dereferencing only a single level
|
|
|
|
|
of symbolic ref.
|
|
|
|
|
|
2007-01-26 22:26:10 +00:00
|
|
|
-m::
|
|
|
|
|
Update the reflog for <name> with <reason>. This is valid only
|
|
|
|
|
when creating or updating a symbolic ref.
|
|
|
|
|
|
2006-11-30 10:50:28 +00:00
|
|
|
NOTES
|
|
|
|
|
-----
|
|
|
|
|
In the past, `.git/HEAD` was a symbolic link pointing at
|
|
|
|
|
`refs/heads/master`. When we wanted to switch to another branch,
|
|
|
|
|
we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we wanted
|
2005-10-04 23:45:01 +00:00
|
|
|
to find out which branch we are on, we did `readlink .git/HEAD`.
|
2011-12-07 15:20:16 +00:00
|
|
|
But symbolic links are not entirely portable, so they are now
|
|
|
|
|
deprecated and symbolic refs (as described above) are used by
|
|
|
|
|
default.
|
2005-10-04 23:45:01 +00:00
|
|
|
|
2010-01-09 23:33:00 +00:00
|
|
|
'git symbolic-ref' will exit with status 0 if the contents of the
|
2007-01-15 22:25:33 +00:00
|
|
|
symbolic ref were printed correctly, with status 1 if the requested
|
|
|
|
|
name is not a symbolic ref, or 128 if another error occurs.
|
|
|
|
|
|
2005-10-04 23:45:01 +00:00
|
|
|
GIT
|
|
|
|
|
---
|
2008-06-06 07:07:32 +00:00
|
|
|
Part of the linkgit:git[1] suite
|