Finn Arne Gangstad <finnag@xxxxxxx> writes: > On Sat, Mar 21, 2009 at 12:58:33AM -0700, Junio C Hamano wrote: > [...] >> * fg/push-default (Mon Mar 16 16:42:52 2009 +0100) 2 commits >> - Display warning for default git push with no push.default config >> + New config push.default to decide default behavior for push >> >> Replaced the old series with the first step to allow a smooth transition. >> Some might argue that this should not give any warning but just give users >> this new configuration to play with first, and after we know we are going >> to switch default some day, start the warning. > > If you feel that talking about a possible future change is premature, > you could omit that part of the second commit I guess, but I think > printing some kind of warning is valuable. Are you waiting for more > input? It seems that this topic is pretty dead now. > > Most people who get bitten by this directly are probably not active on > this list so I don't think you will hear from many of them. I have already judged that the cause of this series is good, and that is why the series was even considered to be in git.git to begin with. I also looked at the code change in them, and I found it Ok, and that is why the first one is queued in 'next'. At this point we do not need "Yes, it is a good idea" from people, even though "No, it is a horrible change because of such and such reasons" could reverse its course, if the argument is new. The reason the patch has been sitting in 'next' is entirely unrelated to the above. It is to hear from people about unintended side effects, if any. It's only been a week, isn't it? Unlike documentation reformatting and other kinds of patches in which potential breakages will not cause a disaster, push is one of the things we would want to keep working for people. In general, the more important the area a patch touches, the patch needs to cook longer in 'next'. -- 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