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 7:20 PM, Daniel Barkalow
<barkalow@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 6 Jul 2015, Junio C Hamano wrote:
>
>> Jacob Keller <jacob.keller@xxxxxxxxx> writes:
>>
>> > I've been looking at the refspecs for git fetch, and noticed that
>> > globs are partially supported. I wanted to use something like:
>> >
>> > refs/tags/some-prefix-*:refs/tags/some-prefix-*
>> >
>> > as a refspec, so that I can fetch only tags which have a specific
>> > prefix. I know that I could use namespaces to separate tags, but
>> > unfortunately, I am unable to fix the tag format. The specific
>> > repository in question is also generating several tags which are not
>> > relevant to me, in formats that are not really useful for human
>> > consumption. I am also not able to fix this less than useful practice.
>> >
>> > However, I noticed that refspecs only support * as a single component.
>> > The match algorithm works perfectly fine, as documented in
>> > abd2bde78bd9 ("Support '*' in the middle of a refspec")
>> >
>> > 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 wouldn't be it, since refs/tags/*:refs/tags/foo/* would have the same
> problem, assuming you didn't set up the push refspec carefully.
>
> I think it was mostly that it would be too easy to accidentally do
> something you don't want by having some other character instead of a
> slash, like refs/heads/*:refs/heads-*.
>
> Aside from the increased risk of hard-to-spot typos leading to very weird
> behavior, nothing actually goes wrong; in fact, I've been using git with
> that check removed for ages because I wanted a refspec like
> refs/heads/something-*:refs/heads/*. And it works fine as a local patch,
> since you don't need your refspec handling to interoperate with other
> repositories.
>
>         -Daniel
> *This .sig left intentionally blank*


Which is why I suggested a patch that adds this behavior conditionally
and only for fetch. This way you don't have to use a local patch, and
it wouldn't hit normal users. Ideally we can add a flag that only
enables it for refspecs that don't interoperate.

Does this seem ok? If so I will go ahead and try to work up a patch

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]