threads / discuss / 12773

Invalid refspec?

Subject: Invalid refspec?

## tl;dr

5 messages between Mar 20, 2008 and Mar 20, 2008.

replies: 4people: 3as markdown or json

Samuel Tardieu· Mar 20, 2008, 10:53 UTC · lore

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/
Daniel Barkalow· Mar 20, 2008, 13:21 UTC · re: Samuel Tardieu · lore

Re: Invalid refspec?

On Thu, 20 Mar 2008, Samuel Tardieu wrote:
Show 11 quoted lines
> 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*
Junio C Hamano· Mar 20, 2008, 16:46 UTC · re: Daniel Barkalow · lore

Re: Invalid refspec?

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.

Daniel Barkalow· Mar 20, 2008, 17:12 UTC · re: Junio C Hamano · lore

Re: Invalid refspec?

On Thu, 20 Mar 2008, Junio C Hamano wrote:
Show 7 quoted lines
> 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*
Junio C Hamano· Mar 20, 2008, 19:08 UTC · re: Daniel Barkalow · lore

Re: Invalid refspec?

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".

← back to recent threads