git-symbolic-ref(1) [suse man page]

GIT-SYMBOLIC-REF(1)						    Git Manual						       GIT-SYMBOLIC-REF(1)

NAME

       git-symbolic-ref - Read and modify symbolic refs

SYNOPSIS

       git symbolic-ref [-q] [-m <reason>] <name> [<ref>]

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> argument to see which branch your working tree is on.

       Given two arguments, creates or updates a symbolic ref <name> to point at the given branch <ref>.

       A symbolic ref is a regular file that stores a string that begins with ref: refs/. For example, your .git/HEAD is a regular file whose
       contents is ref: refs/heads/master.

OPTIONS

       -q, --quiet
	   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.

       -m
	   Update the reflog for <name> with <reason>. This is valid only when creating or updating a symbolic ref.

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 to find out which branch we are on, we did readlink .git/HEAD. This was fine, and
       internally that is what still happens by default, but on platforms that do not have working symlinks, or that do not have the readlink(1)
       command, this was a bit cumbersome. On some platforms, ln -sf does not even work as advertised (horrors). Therefore symbolic links are now
       deprecated and symbolic refs are used by default.

       git symbolic-ref will exit with status 0 if the contents of the symbolic ref were printed correctly, with status 1 if the requested name is
       not a symbolic ref, or 128 if another error occurs.

AUTHOR

       Written by Junio C Hamano <gitster@pobox.com[1]>

GIT

       Part of the git(1) suite

NOTES

	1. gitster@pobox.com
	   mailto:gitster@pobox.com

Git 1.7.1							    07/05/2010						       GIT-SYMBOLIC-REF(1)

GIT-UPDATE-REF(1)						    Git Manual							 GIT-UPDATE-REF(1)

NAME

       git-update-ref - Update the object name stored in a ref safely

SYNOPSIS

       git update-ref [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>])

DESCRIPTION

       Given two arguments, stores the <newvalue> in the <ref>, possibly dereferencing the symbolic refs. E.g. git update-ref HEAD <newvalue>
       updates the current branch head to the new object.

       Given three arguments, stores the <newvalue> in the <ref>, possibly dereferencing the symbolic refs, after verifying that the current value
       of the <ref> matches <oldvalue>. E.g. git update-ref refs/heads/master <newvalue> <oldvalue> updates the master branch head to <newvalue>
       only if its current value is <oldvalue>. You can specify 40 "0" or an empty string as <oldvalue> to make sure that the ref you are creating
       does not exist.

       It also allows a "ref" file to be a symbolic pointer to another ref file by starting with the four-byte header sequence of "ref:".

       More importantly, it allows the update of a ref file to follow these symbolic pointers, whether they are symlinks or these "regular file
       symbolic refs". It follows real symlinks only if they start with "refs/": otherwise it will just try to read them and update them as a
       regular file (i.e. it will allow the filesystem to follow them, but will overwrite such a symlink to somewhere else with a regular
       filename).

       If --no-deref is given, <ref> itself is overwritten, rather than the result of following the symbolic pointers.

       In general, using

	   git update-ref HEAD "$head"

       should be a lot safer than doing

	   echo "$head" > "$GIT_DIR/HEAD"

       both from a symlink following standpoint and an error checking standpoint. The "refs/" rule for symlinks means that symlinks that point to
       "outside" the tree are safe: they'll be followed for reading but not for writing (so we'll never write through a ref symlink to some other
       tree, if you have copied a whole archive by creating a symlink tree).

       With -d flag, it deletes the named <ref> after verifying it still contains <oldvalue>.

LOGGING UPDATES

       If config parameter "core.logAllRefUpdates" is true or the file "$GIT_DIR/logs/<ref>" exists then git update-ref will append a line to the
       log file "$GIT_DIR/logs/<ref>" (dereferencing all symbolic refs before creating the log name) describing the change in ref value. Log lines
       are formatted as:

	1. oldsha1 SP newsha1 SP committer LF

	   Where "oldsha1" is the 40 character hexadecimal value previously stored in <ref>, "newsha1" is the 40 character hexadecimal value of
	   <newvalue> and "committer" is the committer's name, email address and date in the standard GIT committer ident format.

       Optionally with -m:

	1. oldsha1 SP newsha1 SP committer TAB message LF

	   Where all fields are as described above and "message" is the value supplied to the -m option.

       An update will fail (without changing <ref>) if the current user is unable to create a new log file, append to the existing log file or
       does not have committer information available.

AUTHOR

       Written by Linus Torvalds <torvalds@osdl.org[1]>.

GIT

       Part of the git(1) suite

NOTES

	1. torvalds@osdl.org
	   mailto:torvalds@osdl.org

Git 1.7.1							    07/05/2010							 GIT-UPDATE-REF(1)