On Tue, May 01 2018, Wink Saville wrote:
> As discussed on the git email list [1] with the subject
> "Fetching tags overwrites existing tags" there is a bug
> where fetching tags can overwrite existing tags.
>
> Ævar Arnfjörð Bjarmasono, has created a patch series [2]
> which requires a '--force' flag when fetching if the user
> actually wants to overwrite any existing flags.
>
> This patch series allows tags in remotes to be placed in
> a sub hierarchy, refs/remote-tags when "git remote add" is
> passed the --remote-tags option.
>
> The patch series also modifies tag so "git tag -l" will list
> tags in refs/remote-tags properly. It also test for
> "git remote add" which uses "git tag -l".
Thanks a lot for working on this, it's great to have something the
direction of getting rid of this discrepancy between the 1=1 mapping for
branches, but the 1=many mapping for tags. My recent patch series and
the pruneTags feature I added in 2.17.0 are really just hacks around not
having that.
My concern with your patches is not that they're not implementing some
mythical future where we're mapping each <remote>'s refs to
remotes/<fully qualified ref> and local refs to local/<fully qualified
ref>, which is what we should really be aiming for and would forever get
us out of this rut of 1=many and local & remote refs existing in the
same namespace, but that they might make it harder to get there.
So specifically, your 1/3 writes this to the config:
[remote "gbenchmark"]
url = git@xxxxxxxxxx:google/benchmark
fetch = +refs/heads/*:refs/remotes/gbenchmark/*
fetch = +refs/tags/*:refs/remote-tags/gbenchmark/*
tagopt = --remote-tags
If the user clones with your patch, and then uses an older git version
on the same repo (a use case we need to support) that older version
doesn't know about --remote-tags, and will fetch them all.
As a workaround for that maybe we'll need something like:
[remote "gbenchmark"]
url = git@xxxxxxxxxx:google/benchmark
fetch = +refs/heads/*:refs/remotes/gbenchmark/*
fetch = +refs/tags/*:refs/remote-tags/gbenchmark/*
tagStyle = remote
tagopt = --no-tags
Or whatever, i.e. something where only the new version will fetch the
tags and ignore the tagopt option (which I never liked anyway). It's a
hack, but at least you don't end up with crap it your ref namespace by
flip-flopping between versions.
Then as I alluded to in my
https://public-inbox.org/git/20180429202100.32353-6-avarab@xxxxxxxxx/ we
have a lot of stuff that hardcodes special behaviors for
refs/{tags,heads}/, including but not limited to:
git grep -C2 -e TAG_REFSPEC -e tag_refspec -e '"refs/tags/' -- '*.[ch]'
So maybe we need to start this series with some set of patches where we
make the currently hardcoded behavior for refs/{heads,tags}/
configurable.
Sorry about this "nice shed you built, how about you make a cathedral
instead?" E-Mail. I really don't think we should make perfect the enemy
of the good, but at the same time it would be unfortunate if we can't
get perfect because we settled for good.
