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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox