On Fri, Feb 22, 2013 at 9:30 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> 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*. > > Exactly. I completely agree. We don't want that [1]. 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 discussed earlier: http://thread.gmane.org/gmane.comp.version-control.git/166223/focus=168238 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 [1] to avoid since it makes the command forever unpredictable. "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? -- David -- 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