Stefan Beller <> 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
More majordomo info at

Reply via email to