On Tue, May 1, 2018 at 12:24 PM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > 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. > I also agree, I'd prefer if we aim for the mapping to be something which works for all refs in the future, even if such support isn't added now, which is why i've proposed using "refs/remote/<name>/" so that a tag would go from refs/tags/v1.7 to refs/remote/<name>/tags/v1.7 Ideally, we could work to update "refs/remotes/<name>" to go to "refs/remote/<name>/heads" as well. This allows obtaining any ref and mapping it safely per remote. I don't really like the fact that we can't simply re-use "remotes", nor do I like the fact that "remote" is very close to "remotes" increasing the chance of typos... historically I suggested using "tracking" but I don't really like that either.. because honestly there *is* no good name left for this purpose once "remotes" became only about branches. The reason I care about this is that I do want to be able to share the notes refs in a way that allows easy merging, which currently is not really doable without a lot of work from all users of notes knowing exactly how you plan to work on them. Thanks, Jake > 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.
