From: Junio C Hamano <gitster@pobox.com>
To: David Bohman <debohman@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: git-2.51.0: Fetching tags does not work
Date: Fri, 05 Sep 2025 21:56:57 -0700 [thread overview]
Message-ID: <xmqqcy8418me.fsf@gitster.g> (raw)
In-Reply-To: <CAB9xhmPcHnB2+i6WeA3doAinv7RAeGs04+n0fHLGToJq=UKUNw@mail.gmail.com> (David Bohman's message of "Fri, 5 Sep 2025 17:30:40 -0700")
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.
next prev parent reply other threads:[~2025-09-06 4:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-06 0:30 git-2.51.0: Fetching tags does not work David Bohman
2025-09-06 4:56 ` Junio C Hamano [this message]
2025-11-03 0:47 ` David Bohman
2025-11-03 1:34 ` rsbecker
2025-11-03 1:45 ` David Bohman
2025-11-03 1:52 ` Chris Torek
2025-11-03 2:38 ` David Bohman
2025-11-03 1:41 ` David Bohman
2025-11-03 8:50 ` Karthik Nayak
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=xmqqcy8418me.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=debohman@gmail.com \
--cc=git@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).