blob: e062030e91ae2b2a25c2ef7bafc4c026015e1f5e [file] [log] [blame]
Junio C Hamano1a4e8412005-12-27 08:17:231git-update-ref(1)
2=================
3
4NAME
5----
6git-update-ref - update the object name stored in a ref safely
7
8SYNOPSIS
9--------
Junio C Hamano341071d2006-06-04 07:24:4810'git-update-ref' [-m <reason>] <ref> <newvalue> [<oldvalue>]
Junio C Hamano1a4e8412005-12-27 08:17:2311
12DESCRIPTION
13-----------
14Given two arguments, stores the <newvalue> in the <ref>, possibly
15dereferencing the symbolic refs. E.g. `git-update-ref HEAD
16<newvalue>` updates the current branch head to the new object.
17
18Given three arguments, stores the <newvalue> in the <ref>,
19possibly dereferencing the symbolic refs, after verifying that
20the current value of the <ref> matches <oldvalue>.
21E.g. `git-update-ref refs/heads/master <newvalue> <oldvalue>`
22updates the master branch head to <newvalue> only if its current
23value is <oldvalue>.
24
25It also allows a "ref" file to be a symbolic pointer to another
26ref file by starting with the four-byte header sequence of
27"ref:".
28
29More importantly, it allows the update of a ref file to follow
30these symbolic pointers, whether they are symlinks or these
31"regular file symbolic refs". It follows *real* symlinks only
32if they start with "refs/": otherwise it will just try to read
33them and update them as a regular file (i.e. it will allow the
34filesystem to follow them, but will overwrite such a symlink to
35somewhere else with a regular filename).
36
37In general, using
38
39git-update-ref HEAD "$head"
40
41should be a _lot_ safer than doing
42
43echo "$head" > "$GIT_DIR/HEAD"
44
45both from a symlink following standpoint *and* an error checking
46standpoint. The "refs/" rule for symlinks means that symlinks
47that point to "outside" the tree are safe: they'll be followed
48for reading but not for writing (so we'll never write through a
49ref symlink to some other tree, if you have copied a whole
50archive by creating a symlink tree).
51
Junio C Hamano341071d2006-06-04 07:24:4852Logging Updates
53---------------
54If config parameter "core.logAllRefUpdates" is true or the file
55"$GIT_DIR/logs/<ref>" exists then `git-update-ref` will append
56a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
57symbolic refs before creating the log name) describing the change
58in ref value. Log lines are formatted as:
59
60 . oldsha1 SP newsha1 SP committer LF
61+
62Where "oldsha1" is the 40 character hexadecimal value previously
63stored in <ref>, "newsha1" is the 40 character hexadecimal value of
64<newvalue> and "committer" is the committer's name, email address
65and date in the standard GIT committer ident format.
66
67Optionally with -m:
68
69 . oldsha1 SP newsha1 SP committer TAB message LF
70+
71Where all fields are as described above and "message" is the
72value supplied to the -m option.
73
74An update will fail (without changing <ref>) if the current user is
75unable to create a new log file, append to the existing log file
76or does not have committer information available.
77
Junio C Hamano1a4e8412005-12-27 08:17:2378Author
79------
80Written by Linus Torvalds <torvalds@osdl.org>.
81
82GIT
83---
84Part of the gitlink:git[7] suite