From: Patrick Steinhardt <ps@pks.im>
To: Toon Claes <toon@iotcl.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v3 4/5] builtin/refs: add "create" subcommand
Date: Mon, 6 Jul 2026 09:12:53 +0200 [thread overview]
Message-ID: <aktVdaB2xRk-iI_8@pks.im> (raw)
In-Reply-To: <87qzlk2m0h.fsf@emacs.iotcl.com>
On Fri, Jul 03, 2026 at 04:19:58PM +0200, Toon Claes wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > diff --git a/Documentation/git-refs.adoc b/Documentation/git-refs.adoc
> > index 6475bdcc62..e6a3528349 100644
> > --- a/Documentation/git-refs.adoc
> > +++ b/Documentation/git-refs.adoc
> > @@ -181,6 +184,53 @@ static int cmd_refs_optimize(int argc, const char **argv, const char *prefix,
> > return pack_refs_core(argc, argv, prefix, repo, refs_optimize_usage);
> > }
> >
> > +static int cmd_refs_create(int argc, const char **argv, const char *prefix,
> > + struct repository *repo)
> > +{
> > + static char const * const refs_create_usage[] = {
> > + REFS_CREATE_USAGE,
> > + NULL
> > + };
> > + const char *message = NULL;
> > + unsigned flags = 0;
> > + struct option opts[] = {
> > + OPT_STRING(0, "message", &message, N_("reason"),
> > + N_("reason of the update")),
> > + OPT_BIT(0 ,"no-deref", &flags,
> > + N_("update <refname> not the one it points to"),
> > + REF_NO_DEREF),
>
> Can `git refs create --no-deref` be used to create symrefs? Should we
> add a test for that? Or can it not
>
> I understand the symmetry, but does it make sense to ask the user to
> create symrefs with `--no-deref`? Feels a bit obscure. The docs say:
>
> `--no-deref`::
> Operate on <ref> itself rather than the reference it points to via a
> symbolic ref.
>
> That's far from obvious for a user to realize they need to pass that
> option if they want to create a symref.
It doesn't cause them to create a symref. What this flag controls is
whether the command would fail when the refname exists already as a
symbolic ref. That is:
$ git symbolic-ref refs/heads/symref refs/heads/target
$ git refs create refs/heads/symref $OID
$ git refs exists refs/heads/target
The git-refs(1) command would have created "refs/heads/target" in this
case, and by passing "--no-deref" you'd instead make it fail.
This flag is somewhat weird. Having it is probably a sensible think to
do, but now that I think about it I wonder whether the default makes all
that much sense in the first place. That being said, _if_ we want to
change it then we should change it for all subcommands.
> > diff --git a/t/t1466-refs-create.sh b/t/t1466-refs-create.sh
> > new file mode 100755
> > index 0000000000..cfb21bf863
> > --- /dev/null
> > +++ b/t/t1466-refs-create.sh
> > @@ -0,0 +1,151 @@
[snip]
> > +test_expect_success 'create fails when the reference already exists' '
> > + test_when_finished "rm -rf repo" &&
> > + setup_repo repo &&
> > + (
> > + cd repo &&
> > + A=$(git rev-parse A) &&
> > + B=$(git rev-parse B) &&
> > + git refs create refs/heads/foo $A &&
> > + test_must_fail git refs create refs/heads/foo $B 2>err &&
> > + test_grep "reference already exists" err &&
> > + test_ref_matches refs/heads/foo "$A"
> > + )
> > +'
>
> I was curious about this test:
>
> test_expect_success 'create succeed when the reference exists with the same value' '
> test_when_finished "rm -rf repo" &&
> setup_repo repo &&
> (
> cd repo &&
> A=$(git rev-parse A) &&
> git refs create refs/heads/foo $A &&
> git refs create refs/heads/foo $A &&
> test_ref_matches refs/heads/foo "$A"
> )
> '
>
> That fails. It that intentional?
Yes, this is intentional. We didn't end up creating the reference, which
is what the user has asked us to do, and hence we fail.
[snip]
> > +test_expect_success 'create with symref target and --no-deref refuses to create reference' '
> > + test_when_finished "rm -rf repo" &&
> > + setup_repo repo &&
> > + (
> > + cd repo &&
> > + A=$(git rev-parse A) &&
> > + git symbolic-ref refs/heads/symref refs/heads/target &&
> > + test_must_fail git refs create --no-deref refs/heads/symref $A 2>err &&
> > + test_grep "dangling symref already exists" err &&
> > + test_must_fail git reflog exists refs/heads/target
> > + )
> > +'
>
> Would it make sense to add this test:
>
> test_expect_success 'create with symref target with --no-deref' '
> test_when_finished "rm -rf repo" &&
> setup_repo repo &&
> (
> cd repo &&
> A=$(git rev-parse A) &&
> git refs create refs/heads/target $A &&
> git refs create --no-deref refs/heads/symref refs/heads/target &&
> git reflog exists refs/heads/symref && false
> )
> '
>
> But that makes me think, this option `--no-deref` is pretty obscure for
> use with `git refs create`. There are two situations:
>
> * The symref doesn't exists: so --no-deref basically is forcing the
> command to create a symref. That's confusing
No, it's not. It tells us that we only want to create the reference if
it doesn't exist and is not a symref. Otherwise, we'd potentially create
the reference that the symref is pointing to.
Patrick
next prev parent reply other threads:[~2026-07-06 7:13 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 8:44 [PATCH 0/4] builtin/refs: add ability to write references Patrick Steinhardt
2026-06-16 8:44 ` [PATCH 1/4] builtin/refs: drop `the_repository` Patrick Steinhardt
2026-06-16 8:44 ` [PATCH 2/4] builtin/refs: add "delete" subcommand Patrick Steinhardt
2026-06-16 8:44 ` [PATCH 3/4] builtin/refs: add "update" subcommand Patrick Steinhardt
2026-06-16 11:17 ` Junio C Hamano
2026-06-17 7:28 ` Patrick Steinhardt
2026-06-17 12:11 ` Junio C Hamano
2026-06-16 14:52 ` Junio C Hamano
2026-06-17 7:28 ` Patrick Steinhardt
2026-06-16 8:44 ` [PATCH 4/4] builtin/refs: add "rename" subcommand Patrick Steinhardt
2026-06-16 14:53 ` Junio C Hamano
2026-06-17 7:28 ` Patrick Steinhardt
2026-06-17 12:13 ` Junio C Hamano
2026-06-17 10:15 ` [PATCH v2 0/5] builtin/refs: add ability to write references Patrick Steinhardt
2026-06-17 10:15 ` [PATCH v2 1/5] builtin/refs: drop `the_repository` Patrick Steinhardt
2026-06-17 10:15 ` [PATCH v2 2/5] builtin/refs: add "delete" subcommand Patrick Steinhardt
2026-06-17 10:16 ` [PATCH v2 3/5] builtin/refs: add "update" subcommand Patrick Steinhardt
2026-06-17 10:16 ` [PATCH v2 4/5] builtin/refs: add "create" subcommand Patrick Steinhardt
2026-06-29 20:58 ` Junio C Hamano
2026-06-30 10:31 ` Patrick Steinhardt
2026-06-17 10:16 ` [PATCH v2 5/5] builtin/refs: add "rename" subcommand Patrick Steinhardt
2026-06-17 12:26 ` [PATCH v2 0/5] builtin/refs: add ability to write references Junio C Hamano
2026-06-29 20:52 ` Junio C Hamano
2026-06-30 10:31 ` Patrick Steinhardt
2026-06-30 11:49 ` [PATCH v3 " Patrick Steinhardt
2026-06-30 11:49 ` [PATCH v3 1/5] builtin/refs: drop `the_repository` Patrick Steinhardt
2026-06-30 11:49 ` [PATCH v3 2/5] builtin/refs: add "delete" subcommand Patrick Steinhardt
2026-07-03 10:54 ` Toon Claes
2026-07-03 12:38 ` Patrick Steinhardt
2026-06-30 11:49 ` [PATCH v3 3/5] builtin/refs: add "update" subcommand Patrick Steinhardt
2026-06-30 11:49 ` [PATCH v3 4/5] builtin/refs: add "create" subcommand Patrick Steinhardt
2026-07-03 14:19 ` Toon Claes
2026-07-06 7:12 ` Patrick Steinhardt [this message]
2026-06-30 11:49 ` [PATCH v3 5/5] builtin/refs: add "rename" subcommand Patrick Steinhardt
2026-07-03 14:31 ` Toon Claes
2026-07-06 7:12 ` Patrick Steinhardt
2026-06-30 19:16 ` [PATCH v3 0/5] builtin/refs: add ability to write references Junio C Hamano
2026-07-06 13:27 ` [PATCH v4 " Patrick Steinhardt
2026-07-06 13:27 ` [PATCH v4 1/5] builtin/refs: drop `the_repository` Patrick Steinhardt
2026-07-06 13:27 ` [PATCH v4 2/5] builtin/refs: add "delete" subcommand Patrick Steinhardt
2026-07-06 13:27 ` [PATCH v4 3/5] builtin/refs: add "update" subcommand Patrick Steinhardt
2026-07-06 13:27 ` [PATCH v4 4/5] builtin/refs: add "create" subcommand Patrick Steinhardt
2026-07-06 13:27 ` [PATCH v4 5/5] builtin/refs: add "rename" subcommand Patrick Steinhardt
2026-07-06 14:57 ` [PATCH v4 0/5] builtin/refs: add ability to write references Junio C Hamano
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=aktVdaB2xRk-iI_8@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=toon@iotcl.com \
/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.