On Oct 22, 2007, at 8:32 AM, Shawn O. Pearce wrote: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. 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Michal Piotrowski | Re: 2.6.23-rc3-mm1 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Fred Tyler | Slow, persistent memory leak in 2.6.20 |
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Antonio Almeida | HTB accuracy for high speed |
