git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: refspecs with '*' as part of pattern

From
Jacob Keller <jacob.keller@gmail.com>
Date
Jul 7, 2015, 02:33 UTC
Message-ID
<CA+P7+xofoxdgQUng1N1NpXyALzjjmAYe++GJoA6qD+zUbZk-vg@mail.gmail.com>
In-Reply-To
<alpine.LNX.2.00.1507062208580.2241@iabervon.iabervon.org>

On Mon, Jul 6, 2015 at 7:20 PM, Daniel Barkalow <barkalow@iabervon.iabervon.org> wrote:

Show 50 quoted lines
> On Mon, 6 Jul 2015, Junio C Hamano wrote:
>
>> Jacob Keller <jacob.keller@gmail.com> 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

Previous: Daniel BarkalowNext: Jacob Keller
Message 5 of 8 in “refspecs with '*' as part of pattern”
  1. Jacob KellerJul 6, 2015
  2. Junio C HamanoJul 6, 2015
  3. Jacob KellerJul 6, 2015
  4. Daniel BarkalowJul 7, 2015
  5. Jacob KellerJul 7, 2015
  6. Jacob KellerJul 7, 2015
  7. Junio C HamanoJul 7, 2015
  8. Jacob KellerJul 7, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.