summaryrefslogtreecommitdiff
path: root/update-ref.c
AgeCommit message (Collapse)AuthorFilesLines
2006-03-23sha1_name: warning ambiguous refs.Libravatar Junio C Hamano1-0/+1
This makes sure that many commands that take refs on the command line to honor core.warnambiguousrefs configuration. Earlier, the commands affected by this patch did not read the configuration file. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-14allow git-update-ref create refs with slashes in namesLibravatar Alex Riesen1-1/+4
Make git-update-ref create references with slashes in them. git-branch and git-checkout already support such reference names. git-branch can use git-update-ref to create the references in a more formal manner now. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-10Fix confusing git-update-ref error messageLibravatar Petr Baudis1-1/+1
When git-update-ref has hit the "Ref %s changed to %s" error, I just stare at it, left puzzled. This patch attempts to reword that to a more useful and less confusing error message. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-14Unlocalized isspace and friendsLibravatar Linus Torvalds1-1/+0
Do our own ctype.h, just to get the sane semantics: we want locale-independence, _and_ we want the right signed behaviour. Plus we only use a very small subset of ctype.h anyway (isspace, isalpha, isdigit and isalnum). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-01Use resolve_ref() to implement read_ref().Libravatar Junio C Hamano1-61/+1
Symbolic refs are understood by resolve_ref(), so existing read_ref() users will automatically understand them as well. Signed-off-by: Junio C Hamano <junio@twinsun.com>
2005-10-01Teach update-ref about a symbolic ref stored in a textfile.Libravatar Junio C Hamano1-1/+14
A symbolic ref is a regular file whose contents is "ref:", followed by optional leading whitespaces, followed by a GIT_DIR relative pathname, followed by optional trailing whitespaces (the optional whitespaces are unconditionally removed, so you cannot have leading nor trailing whitespaces). This can be used in place of a traditional symbolic link .git/HEAD that usually points at "refs/heads/master". You can instead have a regular file .git/HEAD whose contents is "ref: refs/heads/master". [jc: currently the code does not enforce the symbolic ref to begin with refs/, unlike the symbolic link case. It may be worthwhile to require either case to begin with refs/ and not have any /./ nor /../ in them.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-28[PATCH] Make some needlessly global stuff staticLibravatar Peter Hagervall1-1/+1
Insert 'static' where appropriate. Signed-off-by: Peter Hagervall <hager@cs.umu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-25Plug a small race in update-ref.c.Libravatar Junio C Hamano1-4/+22
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-25[PATCH] Add "git-update-ref" to update the HEAD (or other) refLibravatar Linus Torvalds1-0/+111
This is a careful version of the script stuff that currently just blindly writes HEAD with a new value. You can use git-update-ref HEAD <newhead> or git-update-ref HEAD <newhead> <oldhead> where the latter version verifies that the old value of HEAD matches oldhead. It basically 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". NOTE! 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 (ie it will allow the filesystem to follow them, but will overwrite such a symlink to somewhere else with a regular filename). 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). Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>