Re: [BUG] 'add -u' doesn't work from untracked subdir

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Jeff King <peff@peff.net> 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'.