Re: [PATCH v4 14/15] files-backend: remove submodule_allowed from files_downcast()

On 02/20/2017 01:33 PM, Duy Nguyen wrote:

On Mon, Feb 20, 2017 at 7:30 PM, Michael Haggerty [off-list ref] wrote:

quoted

On 02/20/2017 01:21 PM, Duy Nguyen wrote:

quoted

On Mon, Feb 20, 2017 at 7:11 PM, Michael Haggerty [off-list ref] wrote:

quoted

[...]
These limitations, I think, imply that submodule references have to be
treated as read-only.

Behind the scene submodule does add_submodule_odb(), which basically
makes the submodule's odb an alternate of in-core odb. So odb access
works. I was puzzled how submodules could by pass odb access at the
beginning only to find that out. technical/api-ref-iteration.txt also
mentions that you need to add_submodule_odb(), so I think it's
deliberate (albeit hacky) design.

That's interesting. I didn't know it before.

But I still don't think that means that reference writing can work
correctly. If I try to set a submodule branch to an SHA-1 and I verify
that the SHA-1 points to a valid commit, how do I know that the commit
is in the same submodule that holds the reference?

Good point. So will the new flag be "read_only" (no reference to
submodule), or "submodule"? This flag will be passed in at ref-store
init time and kept in files_ref_store.

I haven't checked carefully whether there are other operations that
don't work and/or don't make sense for submodules. If not, then
`read_only` would also be a fine name for the flag.

Michael