Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> Nguyễn Thái Ngọc Duy wrote:
>
>> Convenient function interactive_use() is added for this purpose. The
>> command thinks it's in human hands when:
>
> I admit I really dislike this, especially:
>
>> - GIT_SCRIPTING environment variable is not set
I would have to agree that it is horrible.
> But maybe I'm not the right person to ask, since I'd be okay with
> removing the "s"es (with an appropriate incubation time to discover
> whether we are introducing a regression) unconditionally.
>
> If there is an environment variable to say "I don't want to see
> variations on strings intended for humans", can it be spelled as
> LC_ALL=C?
I have been wondering if we should even care, for two reasons.
* We have had --numstat forever which is exactly what we added for scripts'
use. "I've been parsing that output meant for humans" is not an excuse.
* 'diffstat', at least the recent versions of it (it is hard to track
down historical versions and I gave up [*1*]), gives output like these:
1 file changed, 1 insertion(+)
2 files changed, 3 insertions(+), 1 deletion(-)
0 files changed
The first one does not have anything but a one-line addition to a file,
and we do not even see "0 deletions(-)". The second one is a more
typical example. The third one is "diffstat </dev/null" [*2*].
If we were to touch this, I would prefer to do so unconditionally without
"hrm, can we reliably guess this is meant for humans?" and release it
unceremoniously, perhaps as part of the next release that will have a much
bigger user-visible UI correction to 'merge'.
[Footnote]
*1* I can guess from http://invisible-island.net/diffstat/CHANGES that the
source is probably kept in RCS, but I couldn't find development histories
beyond what is in that file.
*2* We mistakenly applied a patch to make "git apply --stat </dev/null" to
error out recently, which we might want to fix. But that is a separate
topic.
--
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