On Sun, May 10, 2020 at 08:31:26AM -0700, ori@eigenstate.org wrote:
> 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.
 
Interesting.

How can you tell whether a submodule was modified?
I assume you detect the cases where the submodule tree entry no longer
points to the same SHA1 hash ID as it did in the parent tree, or when
the submodule tree entry is no longer present?

What does your implementation do when a new submodule tree entry was added?
Since you call your approach "read-only", I assume such a commit would be
rejected?

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

Yes. That is indeed something we could easily allow.

My question is if that helps a particular use case, or just provides an
illusion that the commit worked fine. Perhaps, in some unlikely case, we
create a commit that Git will end up complaining about? Or create a
condition which some other part of Got will not handle gracefully (which
I believe is far more likely)?

It is another type of node in the repository tree, in addition to files and
directories. So, from a full system design point of view, allowing users
to create, modify, and/or delete submodules may mean that we must handle
this type of tree entry in more places than just when creating commits.

For instance, submodule tree entries may end up clashing with a file or
a directory occupying the same path, during update, rebase, histedit,
backout, and cherrypick. Or clash with files and directories on disk.
We have no code to handle such collisions right now, let alone tests for
such cases, or even basic submodule addition/deletion/modification tests.

With each type of node we allow as a tree entry, our conflict and test
matrix grows by one dimension, and this creates more work for us.
For a feature that, I presume, nobody will ever need to work on OpenBSD code.
The same applies to symlinks, which cannot be committed either right now.

Of course, such problems could already happen today when Got and Git are
used on the same repository. I am assuming a project which starts from
scratch with Got, perhaps importing history from another version control
system, and adapting workflows accordingly if Git compatibility is required.