On Fri, Feb 22, 2013 at 9:30 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Matthieu Moy <matthieu....@grenoble-inp.fr> writes:
>> Yes, but push.default is really different: there is a config variable,
>> and we want the behavior to be configurable. In the case of "git add",
>> I don't think adding a configuration option would be the right thing.
>> That would mean typing "git add -u" on an account which isn't yours will
>> be unpredictable *forever*.
I completely agree. We don't want that .
I'm actually a big enemy of configuration, don't get me wrong.
The real point of the patch I sent was to start a conversation
about the thing I actually care about:
After reading the draft release notes I now realize that
"git add -u" will not die() in Git 2.0. It will operate on the
full tree, as described in the note. Sweet.
I was originally concerned that "git add -u" was going to die()
and we would no longer be able to use it without pathspec.
My concerns were unfounded.
(If I am not understanding this correctly then it is a sign
that the draft release notes can be made more clear)
> Another problem with use2dot0 configuration is that it would invite
> people to imagine that setting it to false will keep the old
> behaviour forever, which is against what you set out to do with the
> patch under discussion.
I agree with both sides. There's the part of me that wants the 2.0
behavior now with a config switch for the same reasons as was
In addition, mindful users would see one less warning,
which is the only weight I've added to that side of the discussion.
We would never want to go back to the old behavior when 2.0
roll around. Jakub's "future.wholeTree" suggestion makes
sense in that context as the entire "future.*" namespace
could be designated as variables with these semantics.
One downside is that adding such a configuration is just more
temporary code to maintain and rip out when 2.0 rolls around.
OTOH a positive thing about adding configuration to get
the better behavior is that the code path materializes
sooner, and it will be better exercised before 2.0. This
increases confidence that removing the false side of the
imaginary "future.fullTree" configuration will be harmless.
In the original-original thread Matthieu and I seemed to
agree that configuration to get the new behavior
(but not get the old behavior) would be nice. Peff went
even farther and suggested that having a way to keep
the old behavior would be good, and I agree that this is
the thing  to avoid since it makes the command forever
"future.*" means the ambiguous/unpredictable behavior
does eventually go away.
It's a flag day, there's no way around that.
Script writers will be hurt, there is no escaping that.
I guess the real question is whether it's a flag day that
happens through availability of configuration, or by the
inevitability of 2.0.
I have one scenario where "future.fullTree" would be
helpful to script writers: it would allow them to
test their scripts with the new behavior and back it out
if their scripts break. This gives them more time to
make the tiny change needed to be portable across
different git versions, which helps make the later
default change into much less of an event.
Having such a configuration would probably mean that
git should probably warn for all pathless "git add -u",
even from the root. It will help usher users towards
the new behavior. The current behavior makes the
most sense since we do not have a config variable.
The current behavior is certainly the simplest.
I don't know what we can do about the clueless user on
stackoverflow that follows the first suggestion to
set the future.fullTree variable. My gut feeling is
that optimizing for them is a lost cause.
Providing a way for mindful users to ease themselves
into the new behavior does help them, and git is
certainly the tool of choice for the mindful user. ;-)
I hope I haven't misrepresented anybody's opinions.
If I'm the only one who thinks that "future.fullTree"
is a good idea then I have no problem with the current
behavior since the noisy warning will be gone in 2.0.
Does anyone else have any weight to add to either side?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html