Carlos Martín Nieto <cmn@xxxxxxxx> writes: > Now comes the interesting part: when --tags is given, there is no > refspec set up, fetch just sets up a global variable. What I'm > thinking (and going to implement after dinner, unless people cry out > against it) is this: just before calling prune_refs, add a refspec to > the user-provided list with the refspec refs/tags/*:refs/tags/* > similar to what fetch_one does if you gave it "tag v1.5.6". This would > cause us to ignore the configured refspec and keep the branches. The > lack of '+' is most certainly on purpose. Is there anything > fundamentally wrong with that idea? It sounds like that the approach should work and preserve the current "fetch --tags" semantics, but with one small caveat (which is not a downside). As was discussed in a few separate threads last month, in the longer term I think we should fix the semantics of "fetch --tags" to mean "in addition to what you usually fetch with the configured refspecs, add that all matching refs/tags/*:refs/tags/* to the refspec" to reduce confusion. "Only fetch tags" may make sense if you have everything else, but by itself it is somewhat a senseless thing to do. The semantics has been kept this way only from fear of breaking backward compatibility, but because nobody wants to only fetch tags without branches, this forces people to say "git fetch && git fetch --tags". We should re-evaluate the design and change it at a major version boundary, I would think. And when that happens, we may need to rip out the special case you discussed above. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html