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: >>> On 02/18/2017 02:33 PM, Nguyễn Thái Ngọc Duy wrote: >>>> Since submodule or not is irrelevant to files-backend after the last >>>> patch, remove the parameter from files_downcast() and kill >>>> files_assert_main_repository(). >>>> >>>> PS. This implies that all ref operations are allowed for submodules. But >>>> we may need to look more closely to see if that's really true... >>> >>> I think you are jumping the gun here. >>> >>> Even after your changes, there is still a significant difference between >>> the main repository and submodules: we have access to the object >>> database for the main repository, but not for submodules. >>> >>> So, for example, the following don't work for submodules: >>> >>> * `parse_object()` is used to ensure that references are only pointed at >>> valid objects, and that branches are only pointed at commit objects. >>> >>> * `peel_object()` is used to write the peeled version of references in >>> `packed-refs`, and to peel references while they are being iterated >>> over. Since this doesn't work, I think you can't write `packed-refs` in >>> a submodule. >>> >>> 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. -- Duy