Duy Nguyen [off-list ref] writes:
Post-shower thoughts. In a tree object, a submodule entry consists of
perm (S_IFGITLINK), hash (which is the external hash) and path. We
could fill the "hash" part with all zero (invalid, signature of new
submodule hash format), then append "/<hashtype>:<external hash>" to
the "path" part. This way we don't have to update tree object or index
format. And I suspect the "path" part is available everywhere we need
to handle submodules already, so extracting the external hash should
be possible...
Even though that single operation might be possible, do not go
there. A "pathname" identifies a "path", not its contents, and
"appending crap after path" breaks the data model badly. Also other
things like merge, checkout and diff would break by butchering
ordering the entries in tree objects.
On Tue, Jul 19, 2016 at 7:06 PM, Junio C Hamano [off-list ref] wrote:
Duy Nguyen [off-list ref] writes:
quoted
Post-shower thoughts. In a tree object, a submodule entry consists of
perm (S_IFGITLINK), hash (which is the external hash) and path. We
could fill the "hash" part with all zero (invalid, signature of new
submodule hash format), then append "/<hashtype>:<external hash>" to
the "path" part. This way we don't have to update tree object or index
format. And I suspect the "path" part is available everywhere we need
to handle submodules already, so extracting the external hash should
be possible...
Even though that single operation might be possible, do not go
there. A "pathname" identifies a "path", not its contents, and
"appending crap after path" breaks the data model badly. Also other
things like merge, checkout and diff would break by butchering
ordering the entries in tree objects.
I thought about that but I thought all those operations required
special treatment for submodules anyway. But I forgot about d/f
conflicts so yeah it's a bad idea. We still have some invalid "mode"
combination that can be used as S_IFGITLINK2, then we can have
variable length hash field in the entry.
--
Duy