Stefan Beller <sbel...@google.com> 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
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html