On Thu, Feb 21, 2013 at 10:23 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > David Aguilar <davvid@xxxxxxxxx> writes: > >> When "git add -u" is invoked from a subdirectory it prints a >> loud warning message about an upcoming Git 2.0 behavior change. >> Some users do not care to be warned. Accomodate them. > > I do not think this is what we discussed to do. > > It was very much deliberate to make the way to "squelch the warning" > not a "set once and *forget*", aka configuration variable, but a > simple-to-type extra command line argument i.e. "git add -u .", that > you will *always* type to train your fingers to explicitly say what > you mean, so that the default switch will not matter to existing > users. In my use case: - The user is always in a subdir; the behavior change is immaterial to them. - The user does not care about these details, and is not harmed by using the short and sweet command. Please enlighten me. Are we really getting rid of it and replacing it with ":/"? That syntax looks like a meh face.. just sayin' I was actually surprised when "add -u" didn't do the whole tree and am happy that 2.0 will make it do the right thing... (and perhaps I am deluded, and am not aware of what 2.0 will do when not given pathspecs.. is it really going to die()? that's so mean! ;) Sorry if I am missing most of the context. I was reading this in builtin/add.c: /* * To be consistent with "git add -p" and most Git * commands, we should default to being tree-wide, but * this is not the original behavior and can't be * changed until users trained themselves not to type * "git add -u" or "git add -A". For now, we warn and * keep the old behavior. Later, this warning can be * turned into a die(...), and eventually we may * reallow the command with a new behavior. */ ...and I was being too optimistic about, "and eventually". I misread that and thought it meant that (eventually) 2.0 would default to the full tree and fix the consistency. I didn't think that meant 2.0 would die and "git add -u" will not be a valid syntax anymore. Why punish these users? They are going to have :/ face. Unlike push.default, whose warning can be silenced with configuration, git 1.x does not have a way to silence this warning without retraining existing users. In other words I will have to answer an email about it one day, and I'm lazy ;-) Another example... $ git grep 'stuff' :/ would it be too much to teach it to do: $ git grep -u 'stuff' (some users are really simple...) but in 2.0 that -u would be a no-op because "grep" will be full tree, no? Would having that as an option and configuration be a way to allow 1.x users to transition themselves to a 2.0 world? I need to read the old discussions. Can someone tell me the magic google search syntax they use to dig them up? Would a better way be a method to make "git add -u" behave like 2.0 today? I'm thinking of Python's "from __future__ import better_behavior" as a analog. If full-tree is a better default then that should be the default. Surely that's better than die(), no? Apologies in advance as I have not read the discussions (yet). -- 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