threads / discuss / 63607

Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

Subject: Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

## tl;dr

14 messages between Jun 9, 2025 and Jul 11, 2025.

replies: 13people: 6as markdown or json

M Hickford· Jun 9, 2025, 07:00 UTC · lore

Hi. Presently, the error "tag ... already exists" doesn't distinguish between tagging the same commit or a different commit:

     >git tag hello v1.9.5
     >git tag hello v1.9.5
     fatal: tag 'hello' already exists
     >git tag hello v2.0.0
     fatal: tag 'hello' already exists
To inform the user, it would be nice to distinguish these cases, perhaps:
     >git tag hello v1.9.5
     fatal: tag 'hello' already exists pointing at
d4e6038a068d0aecd5ec28c83afbfc6d4903092f
     >git tag hello v2.0.0
     fatal: tag 'hello' already exists but points at
18a07354e33f86c8349ffdc300d9087876658264
The second error is typically more concerning than the first.
What do you think?
Junio C Hamano· Jun 9, 2025, 18:42 UTC · re: M Hickford · lore

Re: Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

M Hickford <mirth.hickford@gmail.com> writes:
Show 24 quoted lines
> Hi. Presently, the error "tag ... already exists" doesn't distinguish
> between tagging the same commit or a different commit:
>
>      >git tag hello v1.9.5
>
>      >git tag hello v1.9.5
>      fatal: tag 'hello' already exists
>
>      >git tag hello v2.0.0
>      fatal: tag 'hello' already exists
>
> To inform the user, it would be nice to distinguish these cases, perhaps:
>
>      >git tag hello v1.9.5
>      fatal: tag 'hello' already exists pointing at
> d4e6038a068d0aecd5ec28c83afbfc6d4903092f
>
>      >git tag hello v2.0.0
>      fatal: tag 'hello' already exists but points at
> 18a07354e33f86c8349ffdc300d9087876658264
>
> The second error is typically more concerning than the first.
>
> What do you think?

Not interested. When the user gets that "fatal" message, the existing tag did not get modified, so they can just do whatever check they want (like "git range-diff v1.9.5...hello") themselves.

Besides, in the above examples, is d4e6038a something the user immediately recognises as the same as v1.9.5 or the object existing v1.9.5 tag points at? I somehow doubt it. So after getting the error, there needs some digging to figure out how v1.9.5 and existing hello are related to each other _anyway_, I would think.

Hilco Wijbenga· Jun 9, 2025, 19:37 UTC · re: Junio C Hamano · lore

Re: Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

Does it really make sense for that first example to fail, though? "git tag hello v1.9.5" is an idempotent operation, isn't it? The second attempt is a no-op?

If "git tag ..." simply does nothing if the tag already exists (as requested) then that would make the OP's issue go away: only the 2nd example would fail.

On Mon, Jun 9, 2025 at 11:45 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 40 quoted lines
>
> M Hickford <mirth.hickford@gmail.com> writes:
>
> > Hi. Presently, the error "tag ... already exists" doesn't distinguish
> > between tagging the same commit or a different commit:
> >
> >      >git tag hello v1.9.5
> >
> >      >git tag hello v1.9.5
> >      fatal: tag 'hello' already exists
> >
> >      >git tag hello v2.0.0
> >      fatal: tag 'hello' already exists
> >
> > To inform the user, it would be nice to distinguish these cases, perhaps:
> >
> >      >git tag hello v1.9.5
> >      fatal: tag 'hello' already exists pointing at
> > d4e6038a068d0aecd5ec28c83afbfc6d4903092f
> >
> >      >git tag hello v2.0.0
> >      fatal: tag 'hello' already exists but points at
> > 18a07354e33f86c8349ffdc300d9087876658264
> >
> > The second error is typically more concerning than the first.
> >
> > What do you think?
>
> Not interested.  When the user gets that "fatal" message, the
> existing tag did not get modified, so they can just do whatever
> check they want (like "git range-diff v1.9.5...hello") themselves.
>
> Besides, in the above examples, is d4e6038a something the user
> immediately recognises as the same as v1.9.5 or the object existing
> v1.9.5 tag points at?  I somehow doubt it.  So after getting the
> error, there needs some digging to figure out how v1.9.5 and
> existing hello are related to each other _anyway_, I would think.
>
>
>
Andreas Schwab· Jun 9, 2025, 20:15 UTC · re: Hilco Wijbenga · lore

Re: Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

On Jun 09 2025, Hilco Wijbenga wrote:
> Does it really make sense for that first example to fail, though? "git
> tag hello v1.9.5" is an idempotent operation, isn't it? The second
> attempt is a no-op?
That's not true if an annotated tag is replaced by a lightweight tag.
-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Junio C Hamano· Jun 9, 2025, 20:19 UTC · re: Hilco Wijbenga · lore

Re: Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
Show 7 quoted lines
> Does it really make sense for that first example to fail, though? "git
> tag hello v1.9.5" is an idempotent operation, isn't it? The second
> attempt is a no-op?
>
> If "git tag ..." simply does nothing if the tag already exists (as
> requested) then that would make the OP's issue go away: only the 2nd
> example would fail.

I do not think I personally mind that direction; when I responded, I thought that in the example, 'hello' is initially pointing at something entirely different (perhaps v2.0.0), though.

But it may be tricky to do, though.

It is easy for lightweight tags, but you'd have to fail an attempt to add an annotated and/or signed tag without -f anyway, so you have to be prepared to answer "why does this behave differently with and without -a/-s?".

Hilco Wijbenga· Jun 9, 2025, 21:03 UTC · re: Junio C Hamano · lore

Re: Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

Clearly, I have not used everything that "git tag" offers. :-)

So, to clarify, I was thinking (naively?) that Git would check that the tag as requested is _exactly_ the same as the existing tag. Only _that_ specific scenario would then not fail.

On Mon, Jun 9, 2025 at 1:19 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 21 quoted lines
>
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>
> > Does it really make sense for that first example to fail, though? "git
> > tag hello v1.9.5" is an idempotent operation, isn't it? The second
> > attempt is a no-op?
> >
> > If "git tag ..." simply does nothing if the tag already exists (as
> > requested) then that would make the OP's issue go away: only the 2nd
> > example would fail.
>
> I do not think I personally mind that direction; when I responded, I
> thought that in the example, 'hello' is initially pointing at
> something entirely different (perhaps v2.0.0), though.
>
> But it may be tricky to do, though.
>
> It is easy for lightweight tags, but you'd have to fail an attempt
> to add an annotated and/or signed tag without -f anyway, so you have
> to be prepared to answer "why does this behave differently with and
> without -a/-s?".
M Hickford· Jun 10, 2025, 07:00 UTC · re: Junio C Hamano · lore

Re: Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

On Mon, 9 Jun 2025 at 19:42, Junio C Hamano <gitster@pobox.com> wrote:
Show 37 quoted lines
>
> M Hickford <mirth.hickford@gmail.com> writes:
>
> > Hi. Presently, the error "tag ... already exists" doesn't distinguish
> > between tagging the same commit or a different commit:
> >
> >      >git tag hello v1.9.5
> >
> >      >git tag hello v1.9.5
> >      fatal: tag 'hello' already exists
> >
> >      >git tag hello v2.0.0
> >      fatal: tag 'hello' already exists
> >
> > To inform the user, it would be nice to distinguish these cases, perhaps:
> >
> >      >git tag hello v1.9.5
> >      fatal: tag 'hello' already exists pointing at
> > d4e6038a068d0aecd5ec28c83afbfc6d4903092f
> >
> >      >git tag hello v2.0.0
> >      fatal: tag 'hello' already exists but points at
> > 18a07354e33f86c8349ffdc300d9087876658264
> >
> > The second error is typically more concerning than the first.
> >
> > What do you think?
>
> Not interested.  When the user gets that "fatal" message, the
> existing tag did not get modified, so they can just do whatever
> check they want (like "git range-diff v1.9.5...hello") themselves.
>
> Besides, in the above examples, is d4e6038a something the user
> immediately recognises as the same as v1.9.5 or the object existing
> v1.9.5 tag points at?  I somehow doubt it.  So after getting the
> error, there needs some digging to figure out how v1.9.5 and
> existing hello are related to each other _anyway_, I would think.
Good point. How about just changing the second error message?
>git tag hello v1.9.5
>git tag hello v1.9.5
fatal: tag 'hello' already exists
>git tag hello v2.0.0
fatal: tag 'hello' already exists but points at a different commit
Junio C Hamano· Jun 10, 2025, 14:51 UTC · re: M Hickford · lore

Re: Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

M Hickford <mirth.hickford@gmail.com> writes:
Show 15 quoted lines
>> Besides, in the above examples, is d4e6038a something the user
>> immediately recognises as the same as v1.9.5 or the object existing
>> v1.9.5 tag points at?  I somehow doubt it.  So after getting the
>> error, there needs some digging to figure out how v1.9.5 and
>> existing hello are related to each other _anyway_, I would think.
>
> Good point. How about just changing the second error message?
>
>>git tag hello v1.9.5
>
>>git tag hello v1.9.5
> fatal: tag 'hello' already exists
>
>>git tag hello v2.0.0
> fatal: tag 'hello' already exists but points at a different commit

Or simply something like this. I am not convinced (yet) that this is a good idea; I merely is showing that the implementation would look like this.

----- >8 -----
Subject: tag: allow idempotent "git tag" without "--force"

When "git tag T O" is told to create a tag pointing at an object O without the "--force" option, it refuses with "tag T already exists", even when T points at O (which makes it a no-op).

Let's allow this "idempotent" case by special casing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin/tag.c  |  2 +-
 t/t7004-tag.sh | 12 +++++++++---
 2 files changed, 10 insertions(+), 4 deletions(-)
diff --git c/builtin/tag.c w/builtin/tag.c
index 4742b27d16..5380a46494 100644
--- c/builtin/tag.c
+++ w/builtin/tag.c
@@ -660,7 +660,7 @@ int cmd_tag(int argc,
 
 	if (refs_read_ref(get_main_ref_store(the_repository), ref.buf, &prev))
 		oidclr(&prev, the_repository->hash_algo);
-	else if (!force)
+	else if (!force && (create_tag_object || !oideq(&object, &prev)))
 		die(_("tag '%s' already exists"), tag);
 
 	opt.message_given = msg.given || msgfile;
diff --git c/t/t7004-tag.sh w/t/t7004-tag.sh
index 10835631ca..9a253a44a8 100755
--- c/t/t7004-tag.sh
+++ w/t/t7004-tag.sh
@@ -126,7 +126,7 @@ test_expect_success 'annotated tag with --create-reflog has correct message' '
 '
 
 test_expect_success '--create-reflog does not create reflog on failure' '
-	test_must_fail git tag --create-reflog mytag &&
+	test_must_fail git tag --create-reflog mytag no-such-object &&
 	test_must_fail git reflog exists refs/tags/mytag
 '
 
@@ -183,8 +183,14 @@ test_expect_success 'listing tags using a non-matching pattern should output not
 
 # special cases for creating tags:
 
-test_expect_success 'trying to create a tag with the name of one existing should fail' '
-	test_must_fail git tag mytag
+test_expect_success 'recreating a tag without --force' '
+	# light-weight tag pointing at the same thing
+	# now succeeds
+	git tag mytag HEAD &&
+	# light-weight tag pointing at a different thing
+	test_must_fail git tag mytag HEAD: &&
+	# creating annotated tag, pointing at the same object.
+	test_must_fail git tag -a -m anno mytag $taggedobject
 '
 
 test_expect_success 'trying to create a tag with a non-valid name should fail' '
Junio C Hamano· Jul 7, 2025, 22:24 UTC · re: Junio C Hamano · lore

Re: Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

Junio C Hamano <gitster@pobox.com> writes:
Show 18 quoted lines
> Or simply something like this.  I am not convinced (yet) that this
> is a good idea; I merely is showing that the implementation would
> look like this.
>
> ----- >8 -----
> Subject: tag: allow idempotent "git tag" without "--force"
>
> When "git tag T O" is told to create a tag pointing at an object O
> without the "--force" option, it refuses with "tag T already exists",
> even when T points at O (which makes it a no-op).
>
> Let's allow this "idempotent" case by special casing.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  builtin/tag.c  |  2 +-
>  t/t7004-tag.sh | 12 +++++++++---
>  2 files changed, 10 insertions(+), 4 deletions(-)

As I see nobody biting, I am inclined to say that this is not such a brilliant idea. Let's chuck it.

Show 44 quoted lines
>
> diff --git c/builtin/tag.c w/builtin/tag.c
> index 4742b27d16..5380a46494 100644
> --- c/builtin/tag.c
> +++ w/builtin/tag.c
> @@ -660,7 +660,7 @@ int cmd_tag(int argc,
>  
>  	if (refs_read_ref(get_main_ref_store(the_repository), ref.buf, &prev))
>  		oidclr(&prev, the_repository->hash_algo);
> -	else if (!force)
> +	else if (!force && (create_tag_object || !oideq(&object, &prev)))
>  		die(_("tag '%s' already exists"), tag);
>  
>  	opt.message_given = msg.given || msgfile;
> diff --git c/t/t7004-tag.sh w/t/t7004-tag.sh
> index 10835631ca..9a253a44a8 100755
> --- c/t/t7004-tag.sh
> +++ w/t/t7004-tag.sh
> @@ -126,7 +126,7 @@ test_expect_success 'annotated tag with --create-reflog has correct message' '
>  '
>  
>  test_expect_success '--create-reflog does not create reflog on failure' '
> -	test_must_fail git tag --create-reflog mytag &&
> +	test_must_fail git tag --create-reflog mytag no-such-object &&
>  	test_must_fail git reflog exists refs/tags/mytag
>  '
>  
> @@ -183,8 +183,14 @@ test_expect_success 'listing tags using a non-matching pattern should output not
>  
>  # special cases for creating tags:
>  
> -test_expect_success 'trying to create a tag with the name of one existing should fail' '
> -	test_must_fail git tag mytag
> +test_expect_success 'recreating a tag without --force' '
> +	# light-weight tag pointing at the same thing
> +	# now succeeds
> +	git tag mytag HEAD &&
> +	# light-weight tag pointing at a different thing
> +	test_must_fail git tag mytag HEAD: &&
> +	# creating annotated tag, pointing at the same object.
> +	test_must_fail git tag -a -m anno mytag $taggedobject
>  '
>  
>  test_expect_success 'trying to create a tag with a non-valid name should fail' '
rsbecker@nexbridge.com· Jul 7, 2025, 23:12 UTC · re: Junio C Hamano · lore

RE: Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

On July 7, 2025 6:24 PM, Junio C Hamano wrote:
Show 22 quoted lines
>Junio C Hamano <gitster@pobox.com> writes:
>
>> Or simply something like this.  I am not convinced (yet) that this is
>> a good idea; I merely is showing that the implementation would look
>> like this.
>>
>> ----- >8 -----
>> Subject: tag: allow idempotent "git tag" without "--force"
>>
>> When "git tag T O" is told to create a tag pointing at an object O
>> without the "--force" option, it refuses with "tag T already exists",
>> even when T points at O (which makes it a no-op).
>>
>> Let's allow this "idempotent" case by special casing.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>>  builtin/tag.c  |  2 +-
>>  t/t7004-tag.sh | 12 +++++++++---
>>  2 files changed, 10 insertions(+), 4 deletions(-)
>
>As I see nobody biting, I am inclined to say that this is not such a
brilliant idea.  Let's
Show 10 quoted lines
>chuck it.
>
>>
>> diff --git c/builtin/tag.c w/builtin/tag.c index
>> 4742b27d16..5380a46494 100644
>> --- c/builtin/tag.c
>> +++ w/builtin/tag.c
>> @@ -660,7 +660,7 @@ int cmd_tag(int argc,
>>
>>  	if (refs_read_ref(get_main_ref_store(the_repository), ref.buf,
&prev))
Show 10 quoted lines
>>  		oidclr(&prev, the_repository->hash_algo);
>> -	else if (!force)
>> +	else if (!force && (create_tag_object || !oideq(&object, &prev)))
>>  		die(_("tag '%s' already exists"), tag);
>>
>>  	opt.message_given = msg.given || msgfile; diff --git
>> c/t/t7004-tag.sh w/t/t7004-tag.sh index 10835631ca..9a253a44a8 100755
>> --- c/t/t7004-tag.sh
>> +++ w/t/t7004-tag.sh
>> @@ -126,7 +126,7 @@ test_expect_success 'annotated tag with
--create-reflog
>has correct message' '
>>  '
>>
>>  test_expect_success '--create-reflog does not create reflog on failure'
'
Show 10 quoted lines
>> -	test_must_fail git tag --create-reflog mytag &&
>> +	test_must_fail git tag --create-reflog mytag no-such-object &&
>>  	test_must_fail git reflog exists refs/tags/mytag  '
>>
>> @@ -183,8 +183,14 @@ test_expect_success 'listing tags using a
>> non-matching pattern should output not
>>
>>  # special cases for creating tags:
>>
>> -test_expect_success 'trying to create a tag with the name of one
existing should
Show 13 quoted lines
>fail' '
>> -	test_must_fail git tag mytag
>> +test_expect_success 'recreating a tag without --force' '
>> +	# light-weight tag pointing at the same thing
>> +	# now succeeds
>> +	git tag mytag HEAD &&
>> +	# light-weight tag pointing at a different thing
>> +	test_must_fail git tag mytag HEAD: &&
>> +	# creating annotated tag, pointing at the same object.
>> +	test_must_fail git tag -a -m anno mytag $taggedobject
>>  '
>>
>>  test_expect_success 'trying to create a tag with a non-valid name should
fail' '

Considering that git tag T O will generally require a git push --force and always a git pull --force in order to update tags on the upstream and receiving an update to the tag locally, I think requiring git tag --force T O when O is different from the current tag is a reasonable idea from a consistency standpoint. I do support the notion of git tag T O not requiring a --force if O is already where the tag is pointing. The only counter case I can really see in this is when -s is used to allow the sign to be updated but even then, does --force really change anything when only signing (I think not) because O does not change. If O changes when signing, I think that --force is almost essential to avoid messing up the signatures.

--Randall
Junio C Hamano· Jul 11, 2025, 19:08 UTC · re: rsbecker@nexbridge.com · lore

Re: Suggestion: error "tag ... already exists" should distinguish between tagging different or same commit:

<rsbecker@nexbridge.com> writes:
Show 7 quoted lines
> Considering that git tag T O will generally require a git push
> --force and always a git pull --force in order to update tags on
> the upstream and receiving an update to the tag locally, I think
> requiring git tag --force T O when O is different from the current
> tag is a reasonable idea from a consistency standpoint. I do
> support the notion of git tag T O not requiring a --force if O is
> already where the tag is pointing.
Yup, that is essentially the idea behind that patch.
> The only counter case I can really see in this is when -s is used
> to allow the sign to be updated but even then, does --force really
> change anything when only signing (I think not) because O does not
> change.

In "git tag -s T O" (or "-a" for that matter), O may not change, but the resulting tag object would certainly be different from the object that is pointed at by the existing tag reference T, due to tagger identity and the message in the tag being different from the original. So even without O changing ...

> If O changes when signing, I think that --force is almost
> essential to avoid messing up the signatures.
... we would require --force and that would be a good thing.
Junio C Hamano· Jul 11, 2025, 19:10 UTC · re: Junio C Hamano · lore

[PATCH] tag: allow idempotent "git tag" without "--force"

When "git tag T O" is told to create a tag pointing at an object O without the "--force" option, it refuses with "tag T already exists", even when T points at O (which makes it a no-op).

Let's allow this "idempotent" case by special casing and making it truly a no-op.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * In thread https://lore.kernel.org/git/xmqqzfefodje.fsf@gitster.g/
   I had a slightly different version but I think the logic flow
   reads better in this version, even though they essentially do the
   same thing.
 builtin/tag.c  |  2 ++
 t/t7004-tag.sh | 12 +++++++++---
 2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index c4bd145831..1dd69b3447 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -647,6 +647,8 @@ int cmd_tag(int argc,
 
 	if (refs_read_ref(get_main_ref_store(the_repository), ref.buf, &prev))
 		oidclr(&prev, the_repository->hash_algo);
+	else if (!create_tag_object && oideq(&object, &prev))
+		exit(0);
 	else if (!force)
 		die(_("tag '%s' already exists"), tag);
 
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 10835631ca..9a253a44a8 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -126,7 +126,7 @@ test_expect_success 'annotated tag with --create-reflog has correct message' '
 '
 
 test_expect_success '--create-reflog does not create reflog on failure' '
-	test_must_fail git tag --create-reflog mytag &&
+	test_must_fail git tag --create-reflog mytag no-such-object &&
 	test_must_fail git reflog exists refs/tags/mytag
 '
 
@@ -183,8 +183,14 @@ test_expect_success 'listing tags using a non-matching pattern should output not
 
 # special cases for creating tags:
 
-test_expect_success 'trying to create a tag with the name of one existing should fail' '
-	test_must_fail git tag mytag
+test_expect_success 'recreating a tag without --force' '
+	# light-weight tag pointing at the same thing
+	# now succeeds
+	git tag mytag HEAD &&
+	# light-weight tag pointing at a different thing
+	test_must_fail git tag mytag HEAD: &&
+	# creating annotated tag, pointing at the same object.
+	test_must_fail git tag -a -m anno mytag $taggedobject
 '
 
 test_expect_success 'trying to create a tag with a non-valid name should fail' '

-- 
2.50.1-396-g5c2aadec13
Justin Tobler· Jul 11, 2025, 20:57 UTC · re: Junio C Hamano · lore

Re: [PATCH] tag: allow idempotent "git tag" without "--force"

On 25/07/11 12:10PM, Junio C Hamano wrote:
Show 6 quoted lines
> When "git tag T O" is told to create a tag pointing at an object O
> without the "--force" option, it refuses with "tag T already exists",
> even when T points at O (which makes it a no-op).
> 
> Let's allow this "idempotent" case by special casing and making it
> truly a no-op.

Not necessarily a strong argument against, but I could maybe see a user only wanting to perform some followup operation if a tag is _actually_ created. For example push the newly created tag:

  git tag T O && git push --tags

To me atleast, the feedback of knowing whether tag was created seems a bit more interesting. I also don't feel super strongly though.

-Justin
Junio C Hamano· Jul 11, 2025, 21:40 UTC · re: Justin Tobler · lore

Re: [PATCH] tag: allow idempotent "git tag" without "--force"

Justin Tobler <jltobler@gmail.com> writes:
> For example push the newly created tag:
>
>   git tag T O && git push --tags

The above is not quite a scalable workflow and is not recommendable, though. What if you are publishing to more than one place, and/or sometimes some of them are not reachable? You want to push out your tag not because you newly created it, but because you know some remotes may not have it for whatever reason. "I just created one" is a crude approximate for the latter. "Last time I created one, it somehow failed to push out" (so I have to try again) needs to be considered.

Having said that, ever since I invented "push --follow-tags", I rarely push tags out just for the sake of pushing them out. Only when the real contents that matter are pushed out, tags that point at them would follow.

> To me atleast, the feedback of knowing whether tag was created seems a bit more
> interesting. I also don't feel super strongly though.

I do not fell strongly one way or anothre, either. Discarding the topic is easier than keeping it for me, so let me mark it for trash bin.

Thanks.

← back to recent threads