On Tue, 22 Apr 2008, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
