On Tue, Nov 15, 2016 at 04:13:51PM -0800, Junio C Hamano wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > > >> "We do not know" ... > > > > ... because there is no way to check for us as we don't have the > > submodule commits. > > > > " We do consider it safe as no one in their sane mind would > > have changed the submodule pointers without having the > > submodule around. If a user did however change the submodules > > without having the submodule commits around, this indicates an > > expert who knows what they were doing." > > I didn't think it through myself to arrive at such a conclusion, but > to me the above sounds like a sensible reasoning [*1*]. I think you have a point here. If I rephrase it like this: "We do consider it safe as no one in their sane mind *could* have changed the submodule pointers without having the submodule around..." Since its actually hard to create such a situation without the submodule commit around I agree here. > *1* My version was more like "we do not know if they would get into > a situation where they do not have enough submodule commits if > we pushed our superproject, but more importantly, we DO KNOW > that it would not help an iota if we pushed our submodule to > them, so there is no point stopping the push of superproject > saying 'no, no, no, you must push the submodule first'". Yes saying that would be wrong. I was rather suggesting that we tell the user that we could not find the submodule commits to and that if he wants to proceed he should either pass --recurse-submodules=no or initialize the submodule. But I think the above reasoning obsoletes my suggestion. I would adjust the comment accordingly but still keep the patch so we have documentation that this behavior is on purpose. Cheers Heiko