mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-06 01:03:02 +01:00
Code Activity
git/builtin-update-ref.c

67 lines
1.4 KiB
C
Raw Normal View History

[PATCH] Add "git-update-ref" to update the HEAD (or other) ref 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>
2005-09-25 20:43:05 +02:00
#include "cache.h"
#include "refs.h"
Make git-update-ref a builtin Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-13 22:22:00 +02:00
#include "builtin.h"
[PATCH] Add "git-update-ref" to update the HEAD (or other) ref 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>
2005-09-25 20:43:05 +02:00
Convert update-ref to use ref_lock API. This conversion also adds the '-m' switch to update-ref allowing the caller to record why the ref is changing. At present this is merely copied down into the ref_lock API. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17 11:55:19 +02:00
static const char git_update_ref_usage[] =
git-update-ref: add --no-deref option for overwriting/detaching ref git-checkout is also adapted to make use of this new option instead of the handcrafted command sequence. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-09 12:33:20 +02:00
"git-update-ref [-m <reason>] (-d <refname> <value> | [--no-deref] <refname> <value> [<oldval>])";
Plug a small race in update-ref.c. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-26 01:28:51 +02:00
Call setup_git_directory() much earlier This changes the calling convention of built-in commands and passes the "prefix" (i.e. pathname of $PWD relative to the project root level) down to them. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-29 07:44:25 +02:00
int cmd_update_ref(int argc, const char **argv, const char *prefix)
[PATCH] Add "git-update-ref" to update the HEAD (or other) ref 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>
2005-09-25 20:43:05 +02:00
{
Convert update-ref to use ref_lock API. This conversion also adds the '-m' switch to update-ref allowing the caller to record why the ref is changing. At present this is merely copied down into the ref_lock API. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17 11:55:19 +02:00
const char *refname=NULL, *value=NULL, *oldval=NULL, *msg=NULL;
unsigned char sha1[20], oldsha1[20];
git-update-ref: add --no-deref option for overwriting/detaching ref git-checkout is also adapted to make use of this new option instead of the handcrafted command sequence. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-09 12:33:20 +02:00
int i, delete, ref_flags;
[PATCH] Add "git-update-ref" to update the HEAD (or other) ref 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>
2005-09-25 20:43:05 +02:00
update-ref: -d flag and ref creation safety. This adds -d flag to update-ref to allow safe deletion of ref. Before deleting it, the command checks if the given <oldvalue> still matches the value the caller thought the ref contained. Similarly, it also accepts 0{40} or an empty string as <oldvalue> to allow safe creation of a new ref. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27 10:58:57 +02:00
delete = 0;
git-update-ref: add --no-deref option for overwriting/detaching ref git-checkout is also adapted to make use of this new option instead of the handcrafted command sequence. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-09 12:33:20 +02:00
ref_flags = 0;
sha1_name: warning ambiguous refs. 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>
2006-03-24 08:41:18 +01:00
git_config(git_default_config);
Convert update-ref to use ref_lock API. This conversion also adds the '-m' switch to update-ref allowing the caller to record why the ref is changing. At present this is merely copied down into the ref_lock API. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17 11:55:19 +02:00
for (i = 1; i < argc; i++) {
if (!strcmp("-m", argv[i])) {
if (i+1 >= argc)
usage(git_update_ref_usage);
msg = argv[++i];
if (!*msg)
die("Refusing to perform update with empty message.");
continue;
}
update-ref: -d flag and ref creation safety. This adds -d flag to update-ref to allow safe deletion of ref. Before deleting it, the command checks if the given <oldvalue> still matches the value the caller thought the ref contained. Similarly, it also accepts 0{40} or an empty string as <oldvalue> to allow safe creation of a new ref. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27 10:58:57 +02:00
if (!strcmp("-d", argv[i])) {
delete = 1;
continue;
}
git-update-ref: add --no-deref option for overwriting/detaching ref git-checkout is also adapted to make use of this new option instead of the handcrafted command sequence. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-09 12:33:20 +02:00
if (!strcmp("--no-deref", argv[i])) {
ref_flags |= REF_NODEREF;
continue;
}
Convert update-ref to use ref_lock API. This conversion also adds the '-m' switch to update-ref allowing the caller to record why the ref is changing. At present this is merely copied down into the ref_lock API. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17 11:55:19 +02:00
if (!refname) {
refname = argv[i];
continue;
}
if (!value) {
value = argv[i];
continue;
}
if (!oldval) {
oldval = argv[i];
continue;
}
}
if (!refname || !value)
[PATCH] Add "git-update-ref" to update the HEAD (or other) ref 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>
2005-09-25 20:43:05 +02:00
usage(git_update_ref_usage);
Separate object name errors from usage errors Separate object name errors from usage errors. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-08 23:43:38 +02:00
if (get_sha1(value, sha1))
[PATCH] Add "git-update-ref" to update the HEAD (or other) ref 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>
2005-09-25 20:43:05 +02:00
die("%s: not a valid SHA1", value);
update-ref: -d flag and ref creation safety. This adds -d flag to update-ref to allow safe deletion of ref. Before deleting it, the command checks if the given <oldvalue> still matches the value the caller thought the ref contained. Similarly, it also accepts 0{40} or an empty string as <oldvalue> to allow safe creation of a new ref. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27 10:58:57 +02:00
if (delete) {
if (oldval)
usage(git_update_ref_usage);
return delete_ref(refname, sha1);
}
Convert memset(hash,0,20) to hashclr(hash). In the same spirit as hashcmp() and hashcpy(). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23 22:57:23 +02:00
hashclr(oldsha1);
update-ref: -d flag and ref creation safety. This adds -d flag to update-ref to allow safe deletion of ref. Before deleting it, the command checks if the given <oldvalue> still matches the value the caller thought the ref contained. Similarly, it also accepts 0{40} or an empty string as <oldvalue> to allow safe creation of a new ref. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27 10:58:57 +02:00
if (oldval && *oldval && get_sha1(oldval, oldsha1))
[PATCH] Add "git-update-ref" to update the HEAD (or other) ref 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>
2005-09-25 20:43:05 +02:00
die("%s: not a valid old SHA1", oldval);
Function for updating refs. A function intended to be called from builtins updating refs by locking them before write, specially those that came from scripts using "git update-ref". [jc: with minor fixups] Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-05 03:38:24 +02:00
return update_ref(msg, refname, sha1, oldval ? oldsha1 : NULL,
ref_flags, DIE_ON_ERR);
[PATCH] Add "git-update-ref" to update the HEAD (or other) ref 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>
2005-09-25 20:43:05 +02:00
}
Copy permalink