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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:14

Johannes Schindelin [off-list ref] writes:
On Fri, 8 Jun 2007, Alex Riesen wrote:
quoted
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.

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

From: Daniel Barkalow <hidden>
Date: 2016-06-15 22:43:14

On Thu, 7 Jun 2007, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Fri, 8 Jun 2007, Alex Riesen wrote:
quoted
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*
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help