From: Junio C Hamano <gitster@pobox.com>
To: Miklos Vajna <vmiklos@frugalware.org>
Cc: Jeff King <peff@peff.net>, Brandon Casey <casey@nrlssc.navy.mil>,
git@vger.kernel.org
Subject: Re: [PATCH 1/2] Fix git branch -m for symrefs.
Date: Sat, 25 Oct 2008 11:31:01 -0700 [thread overview]
Message-ID: <7v8wsca5ne.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <a96243124c555cbc4081f733b348252ac200bd53.1224939436.git.vmiklos@frugalware.org> (Miklos Vajna's message of "Sat, 25 Oct 2008 14:58:41 +0200")
Miklos Vajna <vmiklos@frugalware.org> writes:
> -int delete_ref(const char *refname, const unsigned char *sha1)
> +int delete_ref(const char *refname, const unsigned char *sha1, int flags)
> {
> struct ref_lock *lock;
> - int err, i, ret = 0, flag = 0;
> + int err, i = 0, ret = 0, flag = 0;
> + char *path;
>
> lock = lock_ref_sha1_basic(refname, sha1, 0, &flag);
> if (!lock)
> return 1;
> if (!(flag & REF_ISPACKED)) {
Two variables flag vs flags is a bit confusing, isn't it? How about
naming the new one "delopt" or something?
The new variable "char *path" at the toplevel can be confined in the scope
of this if () {} block and probably can become "const char *", right?
> @@ -964,10 +971,15 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
> struct ref_lock *lock;
> struct stat loginfo;
> int log = !lstat(git_path("logs/%s", oldref), &loginfo);
> + const char *symref = NULL;
> + int is_symref = 0;
>
> if (S_ISLNK(loginfo.st_mode))
> return error("reflog for %s is a symlink", oldref);
Possible bug in the context. When there is no reflog for the ref being
renamed, lstat would fail; it doesn't feel right to have this S_ISLNK()
before checking the result of the lstat which is in "log".
> + symref = resolve_ref(oldref, orig_sha1, 0, &flag);
> + if (flag & REF_ISSYMREF)
> + is_symref = 1;
> if (!resolve_ref(oldref, orig_sha1, 1, &flag))
> return error("refname %s not found", oldref);
Do we really need two calls to resolve_ref()? Your new call calls it
without must-exist bit --- why? Immediately after that, the existing call
will barf if it does not exist anyway.
I agree it is good to have symref aware delete_ref(), but I am not sure
supporting symref in rename_ref() is either needed or necessarily a good
idea. You also need to worry about a symref pointing at a branch yet to
be born.
In the meantime, I think we should just check (flag & REF_ISSYMREF) after
the existing resolve_ref() we can see in the context above, and error out
saying you cannot rename a symref, and do nothing else.
next prev parent reply other threads:[~2008-10-25 18:32 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-22 0:23 [PATCH] Implement git remote mv Miklos Vajna
2008-10-22 16:52 ` Brandon Casey
2008-10-23 1:18 ` Miklos Vajna
2008-10-23 3:52 ` Jeff King
2008-10-23 12:56 ` [PATCH] Implement git remote rename Miklos Vajna
2008-10-24 23:33 ` Junio C Hamano
2008-10-25 12:58 ` [PATCH 0/2] Fixes for git branch -m / update-ref --no-deref -d Miklos Vajna
2008-10-25 12:58 ` [PATCH 1/2] Fix git branch -m for symrefs Miklos Vajna
2008-10-25 18:31 ` Junio C Hamano [this message]
2008-10-26 2:33 ` [PATCH 0/3] symref rename/delete fixes Miklos Vajna
2008-10-26 2:33 ` [PATCH 1/3] Fix git branch -m for symrefs Miklos Vajna
2008-10-26 2:33 ` [PATCH 2/3] rename_ref(): handle the case when the reflog of a ref does not exist Miklos Vajna
2008-10-26 2:33 ` [PATCH 3/3] Fix git update-ref --no-deref -d Miklos Vajna
2008-10-27 5:31 ` [PATCH 0/3] symref rename/delete fixes Junio C Hamano
2008-10-27 8:50 ` Miklos Vajna
2008-10-27 19:50 ` Miklos Vajna
2008-10-27 19:50 ` [PATCH 1/3] Disallow git branch -m for symrefs Miklos Vajna
2008-10-27 19:50 ` [PATCH 2/3] rename_ref(): handle the case when the reflog of a ref does not exist Miklos Vajna
2008-10-27 19:50 ` [PATCH 3/3] Fix git update-ref --no-deref -d Miklos Vajna
2008-10-28 23:45 ` [PATCH 0/3] symref rename/delete fixes Miklos Vajna
2008-10-29 0:05 ` [PATCH] git branch -m: forbid renaming of a symref Miklos Vajna
2008-10-25 12:58 ` [PATCH 2/2] Fix git update-ref --no-deref -d Miklos Vajna
2008-11-03 18:26 ` [PATCH] Implement git remote rename Miklos Vajna
2008-11-10 20:42 ` Miklos Vajna
2008-11-10 20:43 ` [PATCH 1/4] remote: add a new 'origin' variable to the struct Miklos Vajna
2008-11-10 20:43 ` [PATCH 2/4] git-remote rename: support remotes->config migration Miklos Vajna
2008-11-10 20:43 ` [PATCH 3/4] git-remote rename: support branches->config migration Miklos Vajna
2008-11-12 0:49 ` Junio C Hamano
2008-11-12 2:01 ` Miklos Vajna
2008-11-12 4:22 ` Junio C Hamano
2008-11-12 17:11 ` [PATCH v2 0/4] " Miklos Vajna
2008-11-12 17:11 ` [PATCH 1/4] remote: add a new 'origin' variable to the struct Miklos Vajna
2008-11-12 17:11 ` [PATCH 2/4] git-remote rename: support remotes->config migration Miklos Vajna
2008-11-12 17:11 ` [PATCH 3/4] git-remote rename: support branches->config migration Miklos Vajna
2008-11-12 17:11 ` [PATCH 4/4] git-remote: document the migration feature of the rename subcommand Miklos Vajna
2008-11-10 20:43 ` Miklos Vajna
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v8wsca5ne.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=casey@nrlssc.navy.mil \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=vmiklos@frugalware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.