On 02/20/2017 01:33 PM, Duy Nguyen wrote: > On Mon, Feb 20, 2017 at 7:30 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: >> On 02/20/2017 01:21 PM, Duy Nguyen wrote: >>> On Mon, Feb 20, 2017 at 7:11 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: >>>> [...] >>>> 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