git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* partial globbing in fetch refspecs broken in v1.5.5
@ 2008-05-16 21:28 Nikolaus Schulz
  2008-05-17  5:22 ` Jeff King
  0 siblings, 1 reply; 3+ messages in thread
From: Nikolaus Schulz @ 2008-05-16 21:28 UTC (permalink / raw)
  To: git

Hi, 

the new refspec parser in v1.5.5 has also broken fetch uses like

    git fetch <url> +refs/heads/<foo>*:refs/remotes/<bar>*. 

Such a refspec works like a charm with git 1.5.4.  In case the usefulness of
such a refspec isn't obvious, here's my use case.  I want to track several
remotes, and in particular a selection of branches from one remote repository,
which has the following branches[1]: 

  HEAD
  candidate
  candidate+patches
  debian-experimental
  debian-sarge
  debian-sid
  maint
  master
  release
  release+patches

With git 1.5.4, I can add the following to .git/config

[remote "debian"]
        url = http://smarden.org/git/git.git
        fetch = +refs/heads/debian-*:refs/remotes/debian/*

...and it will work just like '%'-style pattern matching in Makefiles, e.g.
the remote branch debian-sid becomes remotes/debian/sid.  I find that very
natural; but git v1.5.5 rejects this refspec as invalid.  

I am just a beginner with git, and I do not know if there is any problem with
such a use of refspecs.  But if not, I would like to beg the maintainers to
consider restoring this functionality.

Nikolaus

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: partial globbing in fetch refspecs broken in v1.5.5
  2008-05-16 21:28 partial globbing in fetch refspecs broken in v1.5.5 Nikolaus Schulz
@ 2008-05-17  5:22 ` Jeff King
  2008-05-17 12:23   ` Nikolaus Schulz
  0 siblings, 1 reply; 3+ messages in thread
From: Jeff King @ 2008-05-17  5:22 UTC (permalink / raw)
  To: git

On Fri, May 16, 2008 at 11:28:34PM +0200, Nikolaus Schulz wrote:

> the new refspec parser in v1.5.5 has also broken fetch uses like
> 
>     git fetch <url> +refs/heads/<foo>*:refs/remotes/<bar>*. 

This was intentionally changed in ef00d150 (Tighten refspec processing).
There is some associated discussion in this thread:

  http://mid.gmane.org/7vwso2ieuu.fsf@gitster.siamese.dyndns.org

But I don't see any particular reason why this syntax should not be
allowed (besides, "it was never meant to be supported, so it was causing
other breakage").

-Peff

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: partial globbing in fetch refspecs broken in v1.5.5
  2008-05-17  5:22 ` Jeff King
@ 2008-05-17 12:23   ` Nikolaus Schulz
  0 siblings, 0 replies; 3+ messages in thread
From: Nikolaus Schulz @ 2008-05-17 12:23 UTC (permalink / raw)
  To: git

On Sat, May 17, 2008 at 01:22:12AM -0400, Jeff King wrote:
> On Fri, May 16, 2008 at 11:28:34PM +0200, Nikolaus Schulz wrote:
> 
> > the new refspec parser in v1.5.5 has also broken fetch uses like
> > 
> >     git fetch <url> +refs/heads/<foo>*:refs/remotes/<bar>*. 
> 
> This was intentionally changed in ef00d150 (Tighten refspec processing).
> There is some associated discussion in this thread:
> 
>   http://mid.gmane.org/7vwso2ieuu.fsf@gitster.siamese.dyndns.org

Ah.  I had found that commit, but not this discussion, thanks. 
I don't understand what the problem with packing the OP ran into with
his setup, though (see [1]).

> But I don't see any particular reason why this syntax should not be
> allowed (besides, "it was never meant to be supported, so it was causing
> other breakage").

Which breakage?

Nikolaus

[1] http://article.gmane.org/gmane.comp.version-control.git/77381

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-05-17 12:24 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-16 21:28 partial globbing in fetch refspecs broken in v1.5.5 Nikolaus Schulz
2008-05-17  5:22 ` Jeff King
2008-05-17 12:23   ` Nikolaus Schulz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).