On Oct 22, 2007, at 8:32 AM, Shawn O. Pearce wrote:
* sp/push-refspec (Sun Oct 14 10:54:45 2007 +0200) 6 commits - push, send-pack: use same rules as git-rev-parse to resolve refspecs - add ref_cmp_full_short() comparing full ref name with a short name - push, send-pack: support pushing HEAD to real ref name - rev-parse: teach "git rev-parse --symbolic" to print the full ref name - add get_sha1_with_real_ref() returning full name of ref on demand - push, send-pack: fix test if remote branch exists for colon-less refspec I've briefly looked at this series and there's reasons why its not in next yet.
It's not ready for next. Especially the last patch in the list changes the existing behaviour in a way that might be unexpected by longtime git users. And maybe we even need for the 1.6 cycle before we can change the behaviour of git push.
Its actually something that I'm interested in seeing fixed as the current behavior of how git-push matches refs on the remote side is just plain nuts. I'll look at it further after I get ph/parseopt and cc/skip into next.
I planned to draw a conclusion from the discussion in http://marc.info/?l=git&m=119286893014690&w=2 and send an updated proposal based on what I learnt. But unfortunately I didn't have time yet. My impression now is that the details of the behaviour of "git push" are hard to understand and should be made more explicit. Related tasks are currently encoded in the refspecs, but the details are not always obvious right away: - creation of new branches on the remote side. - deletion of branches on the remote side. - pushing of branches matching on local and remote side. - pushing local branches explicitly to a different ref on the remote. - save newbies from pushing to 'non-standard' location, that is only push to heads and tags. - but also allow to push to funny refs if you force git to do this. All this is related to the topic above, although its maybe too much to be solved at once. Steffen - 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
