On Mon, Jul 6, 2015 at 4:01 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.kel...@gmail.com> writes: > >> What is the reason for not allowing slightly more arbitrary >> expressions? Obviously no more than one *... > > I cannot seem to be able to find related discussions around that > patch, so this is only my guess, but I suspect that this is to > discourage people from doing something like: > > refs/tags/*:refs/tags/foo-* > > which would open can of worms (e.g. imagine you fetch with that > pathspec and then push with refs/tags/*:refs/tags/* back there; > would you now get foo-v1.0.0 and foo-foo-v1.0.0 for their v1.0.0 > tag?) we'd prefer not having to worry about. > > >
That is what I assumed. Would some sort of fetch option you could set in gitconfig be acceptable? Or possibly extending code to verify that it doesn't do something too silly? Like extend it to verify that the per-section path is actually the same? Today you can get a similar issue with refs/tags/*:refs/tags/foo/* It just is easier to fix since they're all name-spaced into foo instead. The issue I have is that I only want to download specific tag format, instead of all tags.. Maybe there is a better way to handle this? Basically, the automated build software that my team uses (I don't have a choice here) generates tags like scm_063015_050528 and then I re-generate human readable tags based on information so they look like driver-name-0-16-3 I don't want to ever pull scm_* tags because these are useless. I have tried very much to change the behavior of the team running the build software, but they refuse to budge (as this software works against CVS/SVN etc, and supports some older work, and they don't want to special case it if they can avoid it). Basically, all I see in my git tags are useless scm tags, and I want to not download them ever. (so that they don't show up as possible refs at all) Is there a possible better solution to this? Regards, Jake -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
