Re: [WARNING] Proposed future changes that are backward incompatible

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

"George Spelvin" <linux@horizon.com> writes:

> The suggestion was in <83vdsefz9j.fsf@kalahari.s2.org>, available as
> http://marc.info/?l=git&m=123216049508531
> but I agree that there was no consensus.  I just thought this thread was
> a good place to elicit discussion, since it would be an incompatible change.
>
>> The only way you could justify such a default change is to say:
>>
>>     Almost all the time, everybody wants to use this new behaviour; the
>>     old behaviour is almost never useful in any situation other than a
>>     narrow corner case; and if somebody wants to do such a useless thing
>>     in a corner case, he can always add " ." at the end, so nothing is
>>     lost.
>>
>> I do not think that is true for the change you are proposing here.  'He
>> can always add " ." at the end' alone is not a good enough justification.
>
> Please forgive me, ...

There is nothing that needs forgiveness.  Discussion is a good thing, as
long as it is not about useless bikeshedding (and I should just learn to
ignore discussions that are useless, instead of getting upset.  Lucikly we
haven't had many).

> ... I thought the above *might* be true, and wanted to provoke
> discussion to see how people felt.

If you suspected that the above may be true, that the new behaviour should
be the default, and that many people may support that view, and wanted to
confirm it, then your justification should have really spelled it out.

> The "consistent with
> git-log and all that stuff" argument is quite persuasive to me, but it's
> a convenience feature, so it depends on how people feel.

Consistency among tools with a similar objective is a good thing to aim
for.

"log" especially "log -p" is about inspecting _changes_ and to understand
the change you would more often than not want to view the change in the
entire context (that is the point of having an atomic while-tree commit).

On the other hand, "grep" is about narrowing down the _state_ you would
want to inspect, and unlike the case when you _inspect changes_ where you
would more often want to have the entire context, you would more often
want to omit unrelated parts of the tree while you are _narrowing down
state_ to inspect.  This is especially true when you run it from a
subdirectory, and by definition when you are already in a subdirectory,
your attention is already narrowed down to the part of the whole tree you
are currently in.

So in that sense, I do not see a "similar objective" between what log and
grep are used for.  They may superficially look similar, but the useful
mode of operation between them can be different because they are used for
different purposes.