On Sun, May 10, 2020 at 12:48:14PM +0200, Sebastien Marie wrote:
> 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.

I agree that this is not ideal.

To some extent Got is all about taking away from what Git can do. We are
basically dealing with the problem of stripping down Git's feature set.

A big question is what we can do in order to make this a painless experience.
It's really a question of what promises we want to make to users of Got.
To which degree is it a copy of Git? To which degree is it a custom VCS?

The basic promise we can make is that it will always be possible to use
Git for doing things that Got cannot do. For submodules, this seems to
be the best anwser so far.

When I started out, the plan was to only re-use the repository format and
throw away everything else. I really did not want to care about any other
aspects of compatibility. Using the repo format was a good choice because
I did not have to reinvent the wheels, and it is a popular format that works
with other tools people are already familiar with.

By now, we also support Git's network protocol to some extent. This happened
not because I really wanted to use that protocol, but because Ori made it
work and showed me that it is extensible enough to achieve the server-side
rebasing feature I want to add in the future. So that's a win-win. We can
now talk to actual Git servers and the planned features can still be
implemented. I don't see any downside there.

Reading submodules was necessary to get tog working on e.g. the pdns repo.
I want tog to work out of the box on any repository rather than throwing
an error because I expect it will be a first impression for anyone who
decides to take a look at Got.

Write support for submodules is indeed an interesting decision. At that point
we start to support submodules to some extent. We cross a line where an
inherent expectation that submodules can be used becomes harder to prevent.

It doesn't help that submodules in particular are not a popular feature
from a VCS developer's point of view. Virtually all SVN developers agree
that implementing svn:externals was a bad idea, while some SVN users tell
me they could not live without them. Such users used to cause the SVN team
a lot of work with dozens of bug reports. Git developers I know tell me
similar stories about submodules. Users love the flexibility of creating
links between their repositories. But all the VCS developers I know hate it.

These features are hard to implement correctly because they break a very
basic property of every VCS design: The repository stops being a single
source of truth, and no longer contains all relevant changes and files.

There are suddenly multiple servers being contacted more or less in parallel,
and authentication has to be managed properly. SSH URLs require running ssh
with a URL that the user did not type. These are two problems which already
have CVE numbers attached in other tools.

In my opinion, the complexity of externals and submodules should be pushed
into build tools and tools for managing project dependencies. The version
control system is the wrong place for this, but it ends up being used for
these purposes because people don't know any better and externals/submodules
make it look easy to do when, actually, under the hood it's not easy at all.

So this is why I'm pushing back on it. I do care about the work you are trying
to get done on Rust, and would like to support it. And I suppose you are not
even the person who decided to use submodules. But someone else did and you
are simply trying to use their repository.

But if we decide to go down the submodules road and start to implement this
feature, I see an endless stream of problems and hard work ahead of us :-/