In Atlassian SourceTree, how to know which tags are only local and which are also in remote?
When creating a tag you get the option "Push tag to: ...", but how to know if a tag has been pushed or not after it is created? I can see all my tags locally, but I need to be sure that they are present in remote so that other developers can pull them.
Even without cloning or fetching, you can check the list of tags on the upstream repo with git ls-remote
:
git ls-remote --tags /url/to/upstream/repo
(as illustrated in "When listing git-ls-remote why there's ā^{}
ā after the tag name?")
xbmono illustrates in the comments that quotes are needed:
git ls-remote --tags /some/url/to/repo "refs/tags/MyTag^{}"
Note that you can always push your commits and tags in one command with (git 1.8.3+, April 2013):
git push --follow-tags
See Push git commits & tags simultaneously.
Regarding Atlassian SourceTree specifically:
Note that, from this thread, SourceTree ONLY shows local tags.
There is an RFE (Request for Enhancement) logged in SRCTREEWIN-4015
since Dec. 2015.
A simple workaround:
see a list of only unpushed tags?
git push --tags
or check the "
Push all tags
" box on the "Push" dialog box, all tags will be pushed to your remote.
That way, you will be "sure that they are present in remote so that other developers can pull them".
Note: Use Git 2.47+ for this command.
A recent update broke "git ls-remote
"(man) used outside a repository, which has been corrected with Git 2.47 (Q4 2024), batch 4.
See commit 9e89dcb (02 Aug 2024) by Patrick Steinhardt (pks-t
).
(Merged by Junio C Hamano -- gitster
-- in commit 7603482, 14 Aug 2024)
builtin/ls-remote
: fall back to SHA1 outside of a repoReported-by: Mike Hommey
Signed-off-by: Patrick Steinhardt
In c8aed5e ("
repository
: stop setting SHA1 as the default object hash", 2024-05-07, Git v2.46.0-rc0 -- merge listed in batch #9), we have stopped setting the default hash algorithm forthe_repository
.
Consequently, code that relies onthe_hash_algo
will now crash when it hasn't explicitly been initialized, which may be the case when running outside of a Git repository.It was reported that
git-ls-remote(1)
may crash in such a way when using a remote helper that advertises refspecs.
This is because the refspec announced by the helper will get parsed during capability negotiation.
At that point we haven't yet figured out what object format the remote uses though, so when run outside of a repository then we will fail.