>> So unless you have a convincing use case that shows that just writing such
>> entries by itself is useful, I would say this where I would draw a line and
>> ask users to use Git instead of Got to work on such projects.
> 
> I understand your point of vue, and I am a bit shared here.
> 
> I agree that for any "real" work (a bit more than regenerate a lock file with
> updated crates as here) I will need complete submodules support, and I wouldn't
> expect Got to provide that.
> 
> On the other hand, forbidding commits whereas the code would be simple seems a
> bit excessive. But it makes the line clear for Got: read-only repository if
> having submodule.
> 
>> To improve the user experience slightly, we could detect this condition and
>> write a specific error message which states that submodules are not supported.
>> We could also warn on checkout/update if such entries appear.
> 
> Yes, it makes sense to have either a specific error message or a warning on
> checkout/update.
> 
> Thanks.
> -- 
> Sebastien Marie

The solution I settled on in git9, which I'm fairly happy
with: *submodule links* are read-only, but as long as you
don't modify them, committing works just fine.

It's easy enough to carry them forward unmodified in tree
objects when creating new commits.