Hello,
John and I wondered about git fetch overwriting local tags. I was sure
enough to claim that git fetch won't overwrite local tags with remote
tags having the same name. But after John pointed me to
http://www.pythian.com/news/9067/on-the-perils-of-importing-remote-tags-in-git/
I tested that (using Debian's 1.7.7.3) and really, git does overwrite
local tags.
Here is my test script:
mkdir a
cd a
echo some content > some_file
git init
git add some_file
git commit -m 'some commit log'
git tag some_tag
cd ..
mkdir b
cd b
echo some different content > another_file
git init
git add another_file
git commit -m 'another commit log'
git tag some_tag
git fetch --tags ../a
After that I have:
git log -1 --oneline some_tag
c4ad89a some commit log
so b's tag was overwritten.
Is this intended?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
On Wed, Nov 23, 2011 at 10:08:21AM +0100, Uwe Kleine-König wrote:
John and I wondered about git fetch overwriting local tags. I was sure
enough to claim that git fetch won't overwrite local tags with remote
tags having the same name. But after John pointed me to
http://www.pythian.com/news/9067/on-the-perils-of-importing-remote-tags-in-git/
I tested that (using Debian's 1.7.7.3) and really, git does overwrite
local tags.
Here is my test script:
[...]
git fetch --tags ../a
[...]
Is this intended?
Sort of.
By default, "git fetch" will "auto-follow" tags; if you fetch a commit
which is pointed to by a tag, then git will fetch that tag, too. So
generally, you shouldn't need to specify "--tags" at all, because you
will already be getting the relevant tags.
The "--tags" option, however, is a short-hand for saying "fetch all of
the tags", and is equivalent to providing the refspec:
git fetch ../a refs/tags/*:refs/tags/*
Which of course will update your local tags with similarly-named ones
from the remote. So in that sense, there is no bug, and it is working
as intended; the problem is that the author's intent was not the same as
your intent. :)
I'm not sure why you're using "--tags" in the first place. That might
help us figure out if there's another way to do what you want that is
safer.
That being said, it would be nice if "--tags" wasn't so surprising.
Three things that I think could help are:
1. We usually require a "+" on the refspec (or "--force") to update
non-fast-forward branches. But there is no such safety on tags
(which generally shouldn't be updated at all). Should we at least
be enforcing the same fast-forward rules on tag fetches (or even
something more strict, like forbidding tag update at all unless
forced)?
2. We don't keep a reflog on tags. Generally there's no point. But
it wouldn't be very expensive (since they don't usually change),
and could provide a safety mechanism here.
3. Keeping tags from remotes in separate namespaces, but collating
them at lookup time. This has been discussed, and I think is
generally a fine idea, but nobody has moved forward with code.
-Peff
Hi Jeff,
On Wed, Nov 23, 2011 at 05:16:58PM -0500, Jeff King wrote:
On Wed, Nov 23, 2011 at 10:08:21AM +0100, Uwe Kleine-König wrote:
quoted
John and I wondered about git fetch overwriting local tags. I was sure
enough to claim that git fetch won't overwrite local tags with remote
tags having the same name. But after John pointed me to
http://www.pythian.com/news/9067/on-the-perils-of-importing-remote-tags-in-git/
I tested that (using Debian's 1.7.7.3) and really, git does overwrite
local tags.
Here is my test script:
[...]
git fetch --tags ../a
[...]
Is this intended?
Sort of.
By default, "git fetch" will "auto-follow" tags; if you fetch a commit
which is pointed to by a tag, then git will fetch that tag, too. So
generally, you shouldn't need to specify "--tags" at all, because you
will already be getting the relevant tags.
Hmm, if I do:
mkdir a
cd a
echo some content > some_file
git init
git add some_file
git commit -m 'some commit log'
git tag some_tag
cd ..
mkdir b
cd b
echo some different content > another_file
git init
git add another_file
git commit -m 'another commit log'
git fetch ../a
I don't get the tag. That's why I added --tags. I guess that's because
some_tag is a lightweight tag. Hmm, but even if I change the command to
create the tag to
git tag -a -m 'tag desc' some_tag
I don't get it without --tags?!
The "--tags" option, however, is a short-hand for saying "fetch all of
the tags", and is equivalent to providing the refspec:
git fetch ../a refs/tags/*:refs/tags/*
Which of course will update your local tags with similarly-named ones
from the remote. So in that sense, there is no bug, and it is working
as intended; the problem is that the author's intent was not the same as
your intent. :)
I'm not sure why you're using "--tags" in the first place. That might
help us figure out if there's another way to do what you want that is
safer.
That being said, it would be nice if "--tags" wasn't so surprising.
Three things that I think could help are:
1. We usually require a "+" on the refspec (or "--force") to update
non-fast-forward branches. But there is no such safety on tags
(which generally shouldn't be updated at all). Should we at least
be enforcing the same fast-forward rules on tag fetches (or even
something more strict, like forbidding tag update at all unless
forced)?
That sounds fine for me.
2. We don't keep a reflog on tags. Generally there's no point. But
it wouldn't be very expensive (since they don't usually change),
and could provide a safety mechanism here.
I prefer 1, but that would be better than the current situation at
least.
3. Keeping tags from remotes in separate namespaces, but collating
them at lookup time. This has been discussed, and I think is
generally a fine idea, but nobody has moved forward with code.
That's something that John said in our discussion, too. That's the
suggestion I like the most.
Best regards and thanks for your time,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |