From: Stefan Sperling <stsp@stsp.name>
Subject: Re: submodules: got: bad file type
To: Sebastien Marie <semarie@online.fr>
Cc: gameoftrees@openbsd.org
Date: Sun, 10 May 2020 10:36:36 +0200

On Sun, May 10, 2020 at 10:00:38AM +0200, Sebastien Marie wrote:
> Hi,
> 
> Working on rust repository currently, I have an error when trying to commit changes on it.
> 
> $ got ci -m 'my changes' Cargo.lock src/librustc_data_structures/Cargo.toml
> M  Cargo.lock
> M  src/librustc_data_structures/Cargo.toml
> got: bad file type
> 
> With few debug printf:
> $ got ci ...
> M  Cargo.lock
> M  src/librustc_data_structures/Cargo.toml
> XXX te_mode=160000 (%o)
> XXX got_object_tree_create: name=llvm-project
> got: bad file type
> 
> the "llvm-project" entry (at src/llvm-project) is a submodule entry (see https://github.com/rust-lang/rust/tree/master/src)
> 
> with tog tree, it is showed as 'llvm-project$'.
> 
> I think it makes sens to permit working with repository with submodules.

We currently do not support submodules. So far, we only support them
when parsing tree objects to avoid a hard error when such tree objects
are read.

Submodules rely on data in Git's configuration file, outside of object
storag,e for consistency. This is a very bad design decision from my
point of view.

Automatically fetching data from URLs stored in repository data is bad
for several reasons. It's one of the areas where most version control
systems ended up with security holes. All of SVN, Git, and Mercurial have
had very bad bugs in such features. And I don't see any need for this in
OpenBSD's workflow, where 3rd party software is imported rather than linked. 

To make committing work in your case, we could allow the creation of this
tree entry as a submodule. But that alone will not make submodules work.
So my next question would be: Does merely writing this tree entry allow
you to do any meaningful work on a project that uses submodules?

My expectation is that once you can make this commit, you will hit another
problem in the workflow, and you won't be able to use Got for this project
until we actually implement proper support for submodules.

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.

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.