Re: refspecs with '*' as part of pattern

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 6, 2015 at 4:01 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jacob Keller <jacob.keller@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]