On Sat, Feb 10, 2018 at 4:21 AM, Jeff King <peff@xxxxxxxx> wrote: > On Sat, Feb 10, 2018 at 01:37:20AM +0100, Leo Gaspard wrote: > >> > Yeah, tag-following may be a little tricky, because it usually wants to >> > write to refs/tags/. One workaround would be to have your config look >> > like this: >> > >> > [remote "origin"] >> > fetch = +refs/heads/*:refs/quarantine/origin/heads/* >> > fetch = +refs/tags/*:refs/quarantine/origin/tags/* >> > tagOpt = --no-tags >> > >> > That's not exactly the same thing, because it would fetch all tags, not >> > just those that point to the history on the branches. But in most >> > repositories and workflows the distinction doesn't matter. >> >> Hmm... apart from the implementation complexity (of which I have no >> idea), is there an argument against the idea of adding a >> remote.<name>.fetchTagsTo refmap similar to remote.<name>.fetch but used >> every time a tag is fetched? (well, maybe not exactly similar to >> remote.<name>.fetch because we know the source is going to be >> refs/tags/*; so just having the part of .fetch past the ':' would be >> more like what's needed I guess) > > I don't think it would be too hard to implement, and is at least > logically consistent with the way we handle tags. > > If we were designing from scratch, I do think this would all be helped > immensely by having more separation of refs fetched from remotes. There > was a proposal in the v1.8 era to fetch everything for a remote, > including tags, into "refs/remotes/origin/heads/", > "refs/remotes/origin/tags/", etc. And then we'd teach the lookup side to > look for tags in each of the remote-tag namespaces. > > I still think that would be a good direction to go, but it would be a > big project (which is why the original stalled). > I want to go this direction, but the difficulty has always been limited time to actually work on such a large project. Thanks, Jake >> The issue with your solution is that if the user runs 'git fetch >> --tags', he will get the (potentially compromised) tags directly in his >> refs/tags/. > > True. > > -Peff
