Jonathan Nieder <jrnie...@gmail.com> writes: >> We are in the middle of 5th week now in the 11-week releace cycle >> for 1.8.4 (http://tinyurl.com/gitCal), and quite a few topics have >> graduated to 'master'. I'd expect the rest of the week to be slow. > > I'd like this or the next release to be 2.0, so the common user > trouble with "git push" pushing more branches than they intended can > be over. Am I crazy? If not, what can I do to help make it happen?
There are currently three topics slated for 2.0 that changes the default behaviours in a big way. The default of the push behaviour switching from matching to simple is one of them, and it has been advertised with advice messages since 1.8.0 (Oct 2012). The other two, "git add -u/-A" without pathspec to operate on the entire tree, and "git add" with pathspec acting as if it were given "-A" option to also record removals to the index, haven't had enough time to be imprinted in users' minds. The former was only mentioned in the release notes of 1.8.2 (Mar 2013), and the advertisement for the latter change appeared first in 1.8.3 (May 2013). I'd prefer to see users have enough time to adjust to these big changes, at least 6 months (but preferrably 9 months). I would say that the change to the default "git push" behaviour may have had enough preparation period, but the other two that are scheduled for 2.0 is way too young. With recent "triangular" addition by Ram, the "simple" mode, the future behaviour of "git push", was again changed, and has not have enough time to mature (isn't it still in 'next'?). Regarding that "simple" thing, I am not sure if the "if you are pushing to a remote that is different from where you fetch from, we do exactly the same as 'current'", which is what we tentatively agreed to implement, is safe enough for new people. I suspect we may want to tighten it a bit more (it would update the branch with the same name as your current local branch, but never try to create such a branch at the remote, for example). So in that sense, even the change to "git push" default may not be old enough for the upcoming release or the next one. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
