On Tue, May 10, 2011 at 03:34:26PM +0000, chris wrote: > I was just taking a queue from the documentation: > > -- > "git push origin master:satellite/master dev:satellite/dev > > Use the source ref that matches master (e.g. refs/heads/master) to update the > ref that matches satellite/master (most probably refs/remotes/satellite/master) > in the origin repository, then do the same for dev and satellite/dev." > -- > > Of course the documentation there is meaninging that > refs/remotes/satellite/master already exists and that there is no conflicting > refs/heads/satellite/master. Right. All of our discussion has been on the case where the RHS doesn't match anything on the remote. > Probably what I need to do is better understand the "guess work" git-push > already does before trying to "improve" it. So, based on this thread and the > documentation, the following holds true: > > $ git push origin HEAD:newbranch > > is valid only if HEAD contains a branch ref pointer. Otherwise, if the LHS of > the refspec is not a known ref type, the RHS must always be explicit when > pushing a new ref. If the LHS is a known ref type, then the same ref type is > used for the RHS of the refspec - also the RHS becomes optional in such a case > and the LHS name will be used if the RHS was omitted. I think the RHS is always optional, isn't it? That is, if I say: git push origin foo then that is always equivalent to git push origin foo:foo which will then push to the matching "foo" on the remote; if it does not exist, then it will infer the type of "foo" on the remote from the type of "foo" locally. But I could be mis-remembering, as it's been a while since I've dug into the refspec code. Other than that, I think your description above is accurate. -Peff -- 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