Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > On Sun, Feb 27, 2011 at 5:46 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Perhaps in this order: >> >> Step 1, as soon as possible: >> >> Â* Introduce "add.make_update_global" configuration variable, and toggle >> Â the above variable when it is explicitly given; also record the fact >> Â that you actually saw this variable in the config parser regardless of >> Â the value that is given; > > Ermm.. compat.make_update_global, with the intent that the config will > be dropped in future (1.9.0 maybe)? As you haven't yet proven that this "new feature" is even useful to help new people nor existing users at this step, you cannot claim "we plan to drop this in the future", hence naming it "compat.*" is a no-go. During this step, we can not even say "we plan to make this the default"; we would confuse the users otherwise (it is fine to say "we might make this the default some day"). Even if we indeed end up proceeding to step 2, I don't see a point in planning to drop the support from the beginning. We might end up doing so, but we can decide when that becomes necessary, and that would be long after the tree-wide default proves a reasonable one, and preferably after seeing a new person or two raise "what's the point of making 'add -u' restricted to cwd? we have too many options and this can go" on the list. Then we would start deprecating the config, giving a warning when people who still rely on their "add.make_update_global = false" say "add -u" without pathspec in a few cycles, and then finally drop it at a version bump boundary. > There's a problem. I use git on many machines. Some will have this > config enabled, some will not (yet). Perhaps a third option, which > will print something when "git add -u" is issued as a reminder? Such a warning would not help you on a machine that does not even have git with Step 1 change. What you conceive as a problem is just a reminder that any incompatible change you plan to add will have pain involved. On two machines, one with a new feature and the other without the new feature, you would have to work differently _or_ you would train yourself to use both versions in a compatible way (e.g. when you mean tree-wide, you would cdup, and when you mean cwd, you would explicitly say ".", from the command line). That is not limited to this particular feature but any incompatible change, no? -- 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