From: Stefan Sperling Subject: Re: submodules: got: bad file type To: Sebastien Marie Cc: gameoftrees@openbsd.org Date: Sun, 10 May 2020 16:37:28 +0200 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 :-/