Junio C Hamano <gitster@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> writes: > >> I suspect it is too late to change it due to compatibility issues. OTOH, >> I think the intent of v1.7.0 is to allow a few small breakages like >> these. You could always write an RFC patch and generate some discussion; >> I'm not 100% sure that there are enough people that agree with us to >> change the default. > > The intent of 1.7.0 is to fix usability glitches and warts that everybody > has long agreed are problematic. People have *just started* discussing > about this---it is not remotely close to "everybody has long agreed are > problematic" criteria. It is too late for 1.7.0. I just wanted to see if I am being fair. Here are the topics that we may have in 1.7.0. * jc/1.7.0-push-safety Prevents gremlin updates from sideways to a repository with a work tree, that confused countless new people. I've resisted this change for a long time on the backward compatiblity ground, but it is very fair to say that it was long agreed that the benefit from the change far outweigh the donesides of having to say "I do want the old behaviour" by setting an configuration variable or two. * jc/1.7.0-send-email-no-thread-default Defaults multi-message send-email to thread shallowly. This change was requested by kernel folks for a long time ago, and discussion on-list resulted in a declaration that unless nobody objects 1.6.2 release notes will say the default will change in 1.6.3. We did not hear any objection, but the switchover did not happen ;-). * jc/1.7.0-status Everybody hated that "status $args" being "commit --dry-run $args" since 1.4.0 days. We will give "commit --dry-run $args" in 1.6.5. * jc/1.7.0-diff-whitespace-only-status We said "diff -w" only affects the appearance but not the exit code, so "diff -w --exit-code" never returned success if there were only whitespace changes. It was noticed to be illogical since day one of the introduction of --exit-code, but we simply did not bother to fix the implementation of -b and -w, since the combination of these two options were thought to be unlikely, and we were simply lazy ;-) I think the first three are clearly 1.7.0 candidates, judging from the benefit/downside perspective and also from the escape-hatch perspective, The last one is probably less so, but on the other hand it is of far lessor impact that we could even roll it out as a bugfix on 'maint'. -- 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