Invalid refspec?

Invalid refspec?

[Samuel Tardieu]

I am using git master branch locally (1.5.5.rc0.133.g7e207), and the
server is using 1.5.4.rc3.g16335. I want to push my HEAD~1 revision
into the 2.0 branch on the server, and it looks like it is not
expanded anymore in the refspec:

% git push origin HEAD~1:2.0
fatal: Invalid refspec 'HEAD~1:2.0'
fatal: The remote end hung up unexpectedly

Isn't HEAD~1 supposed to be expanded locally? Using the SHA-1 instead
of HEAD~1 works fine.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: Invalid refspec?

[Daniel Barkalow]

On Thu, 20 Mar 2008, Samuel Tardieu wrote:

> I am using git master branch locally (1.5.5.rc0.133.g7e207), and the
> server is using 1.5.4.rc3.g16335. I want to push my HEAD~1 revision
> into the 2.0 branch on the server, and it looks like it is not
> expanded anymore in the refspec:
> 
> % git push origin HEAD~1:2.0
> fatal: Invalid refspec 'HEAD~1:2.0'
> fatal: The remote end hung up unexpectedly
> 
> Isn't HEAD~1 supposed to be expanded locally? Using the SHA-1 instead
> of HEAD~1 works fine.

Ah, yes. I added checks for invalid refspecs, and missed that you can use 
things that are invalid as ref names but valid as object names.

We need a test for the src being an object name around line 443 in 
remote.c; I'll have something this evening if nobody beats me to it. For 
now, you can comment out line 444 (except for a semicolon) to disable the 
check that's in your way.

	-Daniel
*This .sig left intentionally blank*

Re: Invalid refspec?

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> We need a test for the src being an object name around line 443 in 
> remote.c; I'll have something this evening if nobody beats me to it.

Careful.  That is ONLY valid for pushes.  For fetches, you are allowed to
name existing refs and nothing else.

Re: Invalid refspec?

[Daniel Barkalow]

On Thu, 20 Mar 2008, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > We need a test for the src being an object name around line 443 in 
> > remote.c; I'll have something this evening if nobody beats me to it.
> 
> Careful.  That is ONLY valid for pushes.  For fetches, you are allowed to
> name existing refs and nothing else.

I think it's okay to make "HEAD~1:foo" *valid* a fetch refspec; it'll be 
rejected a bit further along, but there's no particular need to give a 
different error for "HEAD~1:foo" versus 
"e83c5163316f89bfbde7d9ab23ca2e25604af290:foo" based on the presence of a 
~. Sure, we can figure out a little bit earlier that it's not going to 
work, but I don't think that's really enough to make it important that 
parse_ref_spec reject it.

	-Daniel
*This .sig left intentionally blank*

Re: Invalid refspec?

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> ... but there's no particular need to give a 
> different error for "HEAD~1:foo" versus 
> "e83c5163316f89bfbde7d9ab23ca2e25604af290:foo" based on the presence of a 
> ~.

This is a valid argument in that e83c51... could be (and currently has to
be) a ref name in a fetch refspec.

But we still need to reject something like "HEAD**1:foo".