Re: Friendly refspecs

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Apr 22, 2008, 17:19 UTC
Message-ID: <alpine.LNX.1.00.0804221259180.19665@iabervon.org>
In-Reply-To: <7v63u9zva9.fsf@gitster.siamese.dyndns.org>

On Tue, 22 Apr 2008, Junio C Hamano wrote:

Show 20 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > The "refs/heads/" dwimmery makes sense to me, because:
> >
> >   1. it changes a behavior which is currently an error condition, so
> >      we're not hurting anyone's existing workflow
> >
> >   2. In my usage, pushing a branch to a tag (or vice versa) is the
> >      exception, so I don't mind favoring pushing like types to like
> >      types.
> >
> > But I recognize that (2) is based on my own workflow, so if people
> > disagree, I guess it isn't so for everyone.
> 
> So the proposal is:
> 
> 	"git push $there $commit:$name", when $name does not begin with
> 	refs/, is interpreted as "git push $there $commit:refs/heads/$name"
> 
> right?  I think that makes sense, at least to me.

That's no good for people who make lightweight tags, since those will be commits, and "git push <remote> tag:tag" would push refs/tags/tag to refs/heads/tag.

But I think the proposal was for "git push $there $name:$name", where name gets expanded locally to refs/heads/$name, which I think should probably work. I think it should require $name to be unambiguous locally, though, because it wouldn't be too unusual for people to end up with the same name for a branch and a lightweight tag, and then try pushing that name, expecting one or the other to get pushed.

	-Daniel
*This .sig left intentionally blank*