Stefan Beller <sbeller@xxxxxxxxxx> writes: > I guess we can postpone it until 3.0, though I currently think it is not a big > issue as it helps avoiding "bugs in your workflow". > > On the other hand if you really want to push out the superproject without > the submodules, you need to adapt your behavior (i.e. set an option or > give a command line flag), and such breaking things we should delay > until 3.0. > > I think I'll resend it with a proper commit message, such that we can just pick > it up when 3.0 comes around. A change that needs to wait until a major version bump implies that it is possibly compatibility breaking. So "resend IT", implying one single step, sounds like a bad sign that the users won't have any transition period. Shouldn't we do the usual two-step deprecation process, i.e. warn when an unconfigured user pushes a superproject that may be ahead of a submodule about upcoming planned default change with the first patch, and then flip the default in the second patch while dropping the warning? -- 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