All of lore.kernel.org
 help / color / mirror / Atom feed
From: Toon Claes <toon@iotcl.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v3 4/5] builtin/refs: add "create" subcommand
Date: Thu, 09 Jul 2026 11:53:06 +0200	[thread overview]
Message-ID: <87zf00mqv1.fsf@emacs.iotcl.com> (raw)
In-Reply-To: <aktVdaB2xRk-iI_8@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

> 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

That makes sense. Sort of.

So passing `--no-deref` to `git refs create` in the example above would
make sense if you want creation of refs/heads/target to fail. Okay,
doesn't seem very obvious, but feels correct.

> 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.

Not sure how to make it better, so let's leave it like this.

>> > 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.

Understood.

>> > +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.

Okay, I better understand now with the example above. Thanks!

-- 
Cheers,
Toon

  reply	other threads:[~2026-07-09  9:53 UTC|newest]

Thread overview: 47+ 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
2026-07-09  9:53         ` Toon Claes [this message]
2026-07-09 10:05           ` Toon Claes
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-09  9:44     ` Toon Claes
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=87zf00mqv1.fsf@emacs.iotcl.com \
    --to=toon@iotcl.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ps@pks.im \
    /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.