On Tue, Mar 01, 2011 at 07:51:38PM +0100, Matthieu Moy wrote: > > Once your users (you as a script writer) have an option to set the > > configuration to participate in the tree-wide party early, you would need > > to update your scripts immediately so that they don't break on them; > > But "update" should mean "replace git add -u with git add -u .", which > is the portable way to do the same. > > > so the introduction of the configuration becomes a flag-day event. > > Hmph... > > The introduction of the config variable is a non-event if you already > use the portable . notation. Right. Once this happens, you can never say "git add -u" again portably. You can't rely on the old behavior, because it's changing. You can't rely on the new behavior, because you might be using an old version. So as a script you _must_ say "git add -u .", and if you want top-level behavior and are not at the top-level, you must cd to the toplevel and "add .". Which sounds onerous, but it is what scripts have to do already with the current behavior. > > Yeah, I think you convinced me that an elaborate configuration wouldn't > > help us at all. We just keep warning in 1.7.x series when "add -u" didn't > > see any pathspec, and flip the default at 1.8.0 > > > > Simpler and cleaner ;-) > > I think is still makes sense to have a config variable, so that people > who want the new behavior can get it ASAP. Right after 1.8 is out, I'll > still have machines where I'm too lazy to install a brand new Git, and > I'll want to get the 1.8 goodness for free ;-). Agreed. I also think there should be a setting to keep the current behavior. I don't want to use it, but given that configuration does not introduce any existing portability issues, we can help people who really liked the old behavior. We are inconveniencing them by changing the default, but it seems doubly mean to leave them with no way of restoring it short of typing extra characters on every invocation. -Peff -- 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