git-2.51.0: Fetching tags does not work

git-2.51.0: Fetching tags does not work

[David Bohman]

This is into a bare repository:

git fetch --tags

The command notates the tags it will update, but they do not get added
to the repository.

I reverted to git-2.50.1, and the problem went away. This is a
regression in git-2.51.0.

David Bohman

Re: git-2.51.0: Fetching tags does not work

[Junio C Hamano]

David Bohman <debohman@gmail.com> writes:

> This is into a bare repository:
>
> git fetch --tags
>
> The command notates the tags it will update, but they do not get added
> to the repository.
>
> I reverted to git-2.50.1, and the problem went away. This is a
> regression in git-2.51.0.

The following is my attempt to reproduce ("rungit $version" is my
way to invoke any one of many versions of Git I have installed).

First let's create a bare clone of a repository "foo" in bar.git

: git x; rungit v2.51.0 clone --bare file://$(pwd)/foo bar.git
Cloning into bare repository 'bar.git'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (3/3), done.
: git x; cd bar.git
: git bar.git/BARE:master; rungit v2.51.0 for-each-ref
dcd3daa27e4c2f5182cfa80e5097fed4936b7037 commit refs/heads/master

So now I cloned from "foo" to obtain the "master" branch.  There is
no tag, so nothing else was transferred.

Then we go back to "foo", create a new commit, and a tag.

: git bar.git/BARE:master; cd ../foo
: git foo/master; date >stamp && rungit v2.51.0 commit -a -m "second"
HEAD is now at 2ec78a8 second
: git foo/master; rungit v2.51.0 tag really
: git foo/master; rungit v2.51.0 for-each-ref
2ec78a8e44a74213773a96f6c870b59ae2bfc7f0 commit refs/heads/master
2ec78a8e44a74213773a96f6c870b59ae2bfc7f0 commit refs/tags/really

Now we have an updated branch plus a tag.  We go back to the bare
repository that was created earlier by cloning "foo".

: git foo/master; cd ../bar.git
: git bar.git/BARE:master; rungit v2.51.0 fetch --dry-run
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (3/3), 252 bytes | 63.00 KiB/s, done.
From file:///var/tmp/x/foo
 * branch            HEAD       -> FETCH_HEAD

Without --tags, we would not fetch the tag.

: git bar.git/BARE:master; rungit v2.51.0 fetch --dry-run --tags
From file:///var/tmp/x/foo
 * branch            HEAD       -> FETCH_HEAD
 * [new tag]         really     -> really

With --tags, we would.  After seeing these two dry-run results,
and making sure ...

: git bar.git/BARE:master; rungit v2.51.0 for-each-ref
dcd3daa27e4c2f5182cfa80e5097fed4936b7037 commit refs/heads/master

... dry-runs did not do anything, let's try a fetch for real.

: git bar.git/BARE:master; rungit v2.51.0 fetch --tags
From file:///var/tmp/x/foo
 * branch            HEAD       -> FETCH_HEAD
 * [new tag]         really     -> really
: git bar.git/BARE:master; rungit v2.51.0 for-each-ref
dcd3daa27e4c2f5182cfa80e5097fed4936b7037 commit refs/heads/master
2ec78a8e44a74213773a96f6c870b59ae2bfc7f0 commit refs/tags/really

We have the tag fetched.  Note that this bare clone does not have
any fetch refspec,...

: git bar.git/BARE:master; cat config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
[remote "origin"]
        url = file:///var/tmp/x/foo

...so the master branch hasn't been updated (the new value is only
in FETCH_HEAD, which is expected).

As we can see here, my local copy of 2.51 does not seem to exhibit
such a problem, so you may need to narrow it down a bit more for
others to be able to help.

Thanks.

Re: git-2.51.0: Fetching tags does not work

[David Bohman]

I am sorry to have to bring this up again, but I am still occasionally
seeing this problem with git 2.51.2.

What is happening is that I am cloning a repository as bare, and then
later I try to fetch the new content including the tags:

% ( cd bind9.git; git fetch --tags )
From https://gitlab.isc.org/isc-projects/bind9
 * branch                  HEAD       -> FETCH_HEAD
 ! [rejected]              stable     -> stable  (would clobber existing tag)
 * [new tag]               v9.18.41   -> v9.18.41
 * [new tag]               v9.20.15   -> v9.20.15
 * [new tag]               v9.21.14   -> v9.21.14
% ( cd bind9.git; git fetch --tags )
From https://gitlab.isc.org/isc-projects/bind9
 * branch                  HEAD       -> FETCH_HEAD
 ! [rejected]              stable     -> stable  (would clobber existing tag)
 * [new tag]               v9.18.41   -> v9.18.41
 * [new tag]               v9.20.15   -> v9.20.15
 * [new tag]               v9.21.14   -> v9.21.14
% print $?
1
% ( cd bind9.git; git tag ) | grep v9.20.15
%

As you can see, it is getting an error for one of the tags, but it is
also failing to record the other new tags into the repository.

RE: git-2.51.0: Fetching tags does not work

[rsbecker]

On November 2, 2025 7:47 PM, David Bohman wrote:
>I am sorry to have to bring this up again, but I am still occasionally seeing this
>problem with git 2.51.2.
>
>What is happening is that I am cloning a repository as bare, and then later I try to
>fetch the new content including the tags:
>
>% ( cd bind9.git; git fetch --tags )
>>From https://gitlab.isc.org/isc-projects/bind9
> * branch                  HEAD       -> FETCH_HEAD
> ! [rejected]              stable     -> stable  (would clobber existing tag)
> * [new tag]               v9.18.41   -> v9.18.41
> * [new tag]               v9.20.15   -> v9.20.15
> * [new tag]               v9.21.14   -> v9.21.14
>% ( cd bind9.git; git fetch --tags )
>>From https://gitlab.isc.org/isc-projects/bind9
> * branch                  HEAD       -> FETCH_HEAD
> ! [rejected]              stable     -> stable  (would clobber existing tag)
> * [new tag]               v9.18.41   -> v9.18.41
> * [new tag]               v9.20.15   -> v9.20.15
> * [new tag]               v9.21.14   -> v9.21.14
>% print $?
>1
>% ( cd bind9.git; git tag ) | grep v9.20.15 %
>
>As you can see, it is getting an error for one of the tags, but it is also failing to record
>the other new tags into the repository.

git fetch --tags --force

should clear your situation, where the tag is different on the upstream compare to
your local clone.

Re: git-2.51.0: Fetching tags does not work

[David Bohman]

I am able to reproduce this locally using a bare main repository, a
local bare clone of it, and a non bare clone of the main to insert
revisions and tags into the main. If you move an existing tag in the
main using push -f and then try to fetch --tags into the bare clone,
it fails to insert a new tag into the bare clone:

% ( cd test2.git; git fetch --tags )
From /private/tmp/test
 * branch            HEAD       -> FETCH_HEAD
 ! [rejected]        stable     -> stable  (would clobber existing tag)
 * [new tag]         v5         -> v5
% ( cd test2.git; git fetch --tags )
From /private/tmp/test
 * branch            HEAD       -> FETCH_HEAD
 ! [rejected]        stable     -> stable  (would clobber existing tag)
 * [new tag]         v5         -> v5
% print $?
1
% ( cd test2.git; git fetch --tags )
From /private/tmp/test
 * branch            HEAD       -> FETCH_HEAD
 ! [rejected]        stable     -> stable  (would clobber existing tag)
 * [new tag]         v5         -> v5
% ( cd test2.git; git tag ) | grep v5
%

On Sun, Nov 2, 2025 at 4:47 PM David Bohman <debohman@gmail.com> wrote:
>
> I am sorry to have to bring this up again, but I am still occasionally
> seeing this problem with git 2.51.2.
>
> What is happening is that I am cloning a repository as bare, and then
> later I try to fetch the new content including the tags:
>
> % ( cd bind9.git; git fetch --tags )
> From https://gitlab.isc.org/isc-projects/bind9
>  * branch                  HEAD       -> FETCH_HEAD
>  ! [rejected]              stable     -> stable  (would clobber existing tag)
>  * [new tag]               v9.18.41   -> v9.18.41
>  * [new tag]               v9.20.15   -> v9.20.15
>  * [new tag]               v9.21.14   -> v9.21.14
> % ( cd bind9.git; git fetch --tags )
> From https://gitlab.isc.org/isc-projects/bind9
>  * branch                  HEAD       -> FETCH_HEAD
>  ! [rejected]              stable     -> stable  (would clobber existing tag)
>  * [new tag]               v9.18.41   -> v9.18.41
>  * [new tag]               v9.20.15   -> v9.20.15
>  * [new tag]               v9.21.14   -> v9.21.14
> % print $?
> 1
> % ( cd bind9.git; git tag ) | grep v9.20.15
> %
>
> As you can see, it is getting an error for one of the tags, but it is
> also failing to record the other new tags into the repository.

Re: git-2.51.0: Fetching tags does not work

[David Bohman]

On Sun, Nov 2, 2025 at 5:34 PM <rsbecker@nexbridge.com> wrote:
>
> On November 2, 2025 7:47 PM, David Bohman wrote:
> >I am sorry to have to bring this up again, but I am still occasionally seeing this
> >problem with git 2.51.2.
> >
> >What is happening is that I am cloning a repository as bare, and then later I try to
> >fetch the new content including the tags:
> >
> >% ( cd bind9.git; git fetch --tags )
> >>From https://gitlab.isc.org/isc-projects/bind9
> > * branch                  HEAD       -> FETCH_HEAD
> > ! [rejected]              stable     -> stable  (would clobber existing tag)
> > * [new tag]               v9.18.41   -> v9.18.41
> > * [new tag]               v9.20.15   -> v9.20.15
> > * [new tag]               v9.21.14   -> v9.21.14
> >% ( cd bind9.git; git fetch --tags )
> >>From https://gitlab.isc.org/isc-projects/bind9
> > * branch                  HEAD       -> FETCH_HEAD
> > ! [rejected]              stable     -> stable  (would clobber existing tag)
> > * [new tag]               v9.18.41   -> v9.18.41
> > * [new tag]               v9.20.15   -> v9.20.15
> > * [new tag]               v9.21.14   -> v9.21.14
> >% print $?
> >1
> >% ( cd bind9.git; git tag ) | grep v9.20.15 %
> >
> >As you can see, it is getting an error for one of the tags, but it is also failing to record
> >the other new tags into the repository.
>
> git fetch --tags --force
>
> should clear your situation, where the tag is different on the upstream compare to
> your local clone.
>

Okay, but before 2.51, it would fail to move the existing tag but
still insert the new tags.

Re: git-2.51.0: Fetching tags does not work

[Chris Torek]

> Okay, but before 2.51, it would fail to move the existing tag but
> still insert the new tags.

This is a change in behavior, and no doubt due to the new
reference transaction system: now either all tags get updated,
or none do.

Which behavior is the buggy one is the real question. :-)

Chris

Re: git-2.51.0: Fetching tags does not work

[David Bohman]

On Sun, Nov 2, 2025 at 5:53 PM Chris Torek <chris.torek@gmail.com> wrote:
>
> > Okay, but before 2.51, it would fail to move the existing tag but
> > still insert the new tags.
>
> This is a change in behavior, and no doubt due to the new
> reference transaction system: now either all tags get updated,
> or none do.
>
> Which behavior is the buggy one is the real question. :-)
>
> Chris

I believe that this is a risky change for a mature tool like git. It
has the potential to break all sorts of stuff once it starts to be
adopted out into the wild. Also note that the diagnostic messages are
misleading. It flags the moved tag as an error, but reports the new
tags without error and then fails to insert them.

David

Re: git-2.51.0: Fetching tags does not work

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 2796 bytes --]

David Bohman <debohman@gmail.com> writes:

> I am able to reproduce this locally using a bare main repository, a
> local bare clone of it, and a non bare clone of the main to insert
> revisions and tags into the main. If you move an existing tag in the
> main using push -f and then try to fetch --tags into the bare clone,
> it fails to insert a new tag into the bare clone:
>
> % ( cd test2.git; git fetch --tags )
> From /private/tmp/test
>  * branch            HEAD       -> FETCH_HEAD
>  ! [rejected]        stable     -> stable  (would clobber existing tag)
>  * [new tag]         v5         -> v5
> % ( cd test2.git; git fetch --tags )
> From /private/tmp/test
>  * branch            HEAD       -> FETCH_HEAD
>  ! [rejected]        stable     -> stable  (would clobber existing tag)
>  * [new tag]         v5         -> v5
> % print $?
> 1
> % ( cd test2.git; git fetch --tags )
> From /private/tmp/test
>  * branch            HEAD       -> FETCH_HEAD
>  ! [rejected]        stable     -> stable  (would clobber existing tag)
>  * [new tag]         v5         -> v5
> % ( cd test2.git; git tag ) | grep v5
> %
>

Thanks for reporting back, I missed your first email.

I can confirm that I could reproduce this too. I'm currently looking
into this and I'm certain that this is due to the transaction reference
updates. Nevertheless, I am looking into it and will come back when I
find the cause.

- Karthik

> On Sun, Nov 2, 2025 at 4:47 PM David Bohman <debohman@gmail.com> wrote:
>>
>> I am sorry to have to bring this up again, but I am still occasionally
>> seeing this problem with git 2.51.2.
>>
>> What is happening is that I am cloning a repository as bare, and then
>> later I try to fetch the new content including the tags:
>>
>> % ( cd bind9.git; git fetch --tags )
>> From https://gitlab.isc.org/isc-projects/bind9
>>  * branch                  HEAD       -> FETCH_HEAD
>>  ! [rejected]              stable     -> stable  (would clobber existing tag)
>>  * [new tag]               v9.18.41   -> v9.18.41
>>  * [new tag]               v9.20.15   -> v9.20.15
>>  * [new tag]               v9.21.14   -> v9.21.14
>> % ( cd bind9.git; git fetch --tags )
>> From https://gitlab.isc.org/isc-projects/bind9
>>  * branch                  HEAD       -> FETCH_HEAD
>>  ! [rejected]              stable     -> stable  (would clobber existing tag)
>>  * [new tag]               v9.18.41   -> v9.18.41
>>  * [new tag]               v9.20.15   -> v9.20.15
>>  * [new tag]               v9.21.14   -> v9.21.14
>> % print $?
>> 1
>> % ( cd bind9.git; git tag ) | grep v9.20.15
>> %
>>
>> As you can see, it is getting an error for one of the tags, but it is
>> also failing to record the other new tags into the repository.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]