Re: [PATCH 2/4] add -u: get rid of "treewideupdate" configuration

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

Jeff King <peff@peff.net> writes:

>> What remains is the downside of the configuration variable,
>> namely, that it makes git behave differently depending on who you are and
>> in which repository you are using it, hence making it harder to help
>> and/or teach others.
>
> I have never been a fan of this reasoning. Sure, it is slightly harder
> to help people when the system is configurable. But dropping
> configurability comes at the cost of people who are using the system
> day-to-day. And isn't making it pleasant to use every day more important
> than the minority of times you are telling somebody else how to use it?

I probably should stated it differently.  I dropped it during this round
because they are _not_ needed to help the transition, but it is a possible
additional feature.

Let me try to explain the train of throught a bit better.

People seem to expect "add -u" without any pathspec to work on the whole
working tree structure even when you are in a subdirectory, similar to
"git commit -a".  We will be changing "add -u" in the longer term to do
so.

After the transition happens, people can easily say "add -u ." to limit it
to the current subdirectory, and people can say "add -u ." even today to
be explicit (which would help them transitioning).

Before the transition, however, there is no pleasant way to cause "add -u"
to add everything when you work in a subdirectory, short of saying:

	(cd $(git rev-parse --show-cdup)/. && git add -u)

With ":/", we gain an easy way, "git add -u :/", to say "whole tree".
That is the only thing this series does.

Up to this part, I think we both agree are good thing.

Now, imagine you were born in a world where we had the :/ magic from day
one of git.  Different commands "git add -u", "git grep", "git ls-files"
without pathspec operate differently, and for some reason (e.g. usability,
similarity to other people's corresponding command, or historical reasons)
some of them operate only within the current subdirectory while others
operate on the whole tree.  The default behaviour might even be different
between versions of git or user configuration.

Because we assume that you already have both "." and ":/" to easily be
explicit in that world, "teachers and helpers may have to scratch there
head wasting their time" is no longer an issue.  If you are teaching
others, you ought to know about "." and ":/", and whether we add the
configuration mechanism or not, you ought to know that you should be
explicit to protect yourself from the differences between 1.7.X and 1.8.0
versions in the first place.

So I agree that "costs teachers and helpers" is much less of an issue.

You can certainly introduce configuration variables e.g. "addu.treewide",
"grep.treewide", "lsfiles.treewide" (or even "core.treewide" to cover them
all) to change the default behaviour for each user or each repository.

The real question would become: if it is worth the maintenance cost of
additional code to help users who want to avoid typing "." (or ":/") all
the time in the environment they control.  I don't know the answer to this
question yet.

A good new is that we had to conflate the discussion with "but there is no
pleasant way to tell 'default to local' commands to work on the whole
tree" justification for configuration variables before ":/".  With ":/",
that excuse will be gone and the discussion can be much more simplified.