Re: git-send-pack: broken handling of ref specs with wildcards

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jun 8, 2007, 18:47 UTC
Message-ID: <Pine.LNX.4.64.0706081357420.5848@iabervon.org>
In-Reply-To: <7v8xavlzu0.fsf@assigned-by-dhcp.cox.net>

On Thu, 7 Jun 2007, Junio C Hamano wrote:

Show 23 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Fri, 8 Jun 2007, Alex Riesen wrote:
> >
> >> Try something like this:
> >> 
> >>     git-send-pack --remote=origin --thin /some/other/repo \
> >>     'refs/heads/*:refs/remotes/child/*'
> >> 
> >> The result looks broken: the sent reference are created not in
> >> refs/remotes/child/ but just in refs/heads/ of /some/other/repo.
> >
> > I had the impression that it was git-push, a porcelain, which handles 
> > refspec wildcards, not send-pack, which is plumbing.
> 
> Well, I do not think it is wrong per-se if plumbing send-pack
> starts understanding 'a/*:b/*'.  Earlier it only understood
> concrete refspecs, and such a refspec that has asterisks cannot
> be concrete, as '*' is an invalid char in a refname.  So there
> is no risk of confusion.
> 
> That is, as long as it is done right, which was not true in this
> case.

Good catch; all of my configurations have a {foo}/*:{foo}/* pattern for the push, and I hadn't figured out a way to write tests for push and fetch.

The code looks like it should do the right thing... now that somebody's fixed it before I got to it. You people are far too efficient.

I'll probably break out a function for applying a pattern, since there are multiple places that need to do it, but that can go into a series I'm working on now.

	-Daniel
*This .sig left intentionally blank*