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

quoted text
> 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*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html