Adrian Ratiu [off-list ref] writes:
quoted
It feels somewhat fragile to me that we unconditionally handle these
cases and try to find old submodule directories. If the extension is
enabled I'd expect that the submodule configuration is the _only_ source
of truth.
May I propose that we instead always error out in case the submodule
configuration does not exist? In the best case we'd then give the user a
nice error message that tells them how to run the migration manually.
Junio told me to not do any kind of manual migration and just attempt
new names until one works and then use it consistently.
Indeed, but I do not think that has much relevance to Patrick's
comment. What I meant say was
- With extension, we know that the repository will use the
configuration item as the sole source of truth. Unlike the "we
now store submodule dirs to munged paths" design that we saw long
ago, which would have required us to sometimes move the existing
directories to match the munging scheme, we do not have to
manually migrate the existing directories. Instead, we can just
record the pathnames they already use.
- And with extension, when we add a new submodule, we would need to
give them an entry in the configuration that does not conflict
with those used by the existing submodules. As Patrick mentions,
this name does not have to be done with any reversible mapping,
and third-party software and Git reimplementations can always
refer to the configuration to learn the path without knowing how
the path is chosen themselves.
- The above two would ensure that the configuration would always
exist once a submodule enters our system (and "git submodule init"
is done to cause its gitdir created).
So, unless I am missing some corner case that still exists while
bootstrapping a new style repository with extension, Patrick's
"error when configuration is missing" sounds quite sensible to me.
I am officially still on vacation, so I'd stop here for now ;-).
On Sat, Dec 06, 2025 at 07:47:56AM +0900, Junio C Hamano wrote:
Adrian Ratiu [off-list ref] writes:
quoted
quoted
It feels somewhat fragile to me that we unconditionally handle these
cases and try to find old submodule directories. If the extension is
enabled I'd expect that the submodule configuration is the _only_ source
of truth.
May I propose that we instead always error out in case the submodule
configuration does not exist? In the best case we'd then give the user a
nice error message that tells them how to run the migration manually.
Junio told me to not do any kind of manual migration and just attempt
new names until one works and then use it consistently.
Indeed, but I do not think that has much relevance to Patrick's
comment. What I meant say was
- With extension, we know that the repository will use the
configuration item as the sole source of truth. Unlike the "we
now store submodule dirs to munged paths" design that we saw long
ago, which would have required us to sometimes move the existing
directories to match the munging scheme, we do not have to
manually migrate the existing directories. Instead, we can just
record the pathnames they already use.
- And with extension, when we add a new submodule, we would need to
give them an entry in the configuration that does not conflict
with those used by the existing submodules. As Patrick mentions,
this name does not have to be done with any reversible mapping,
and third-party software and Git reimplementations can always
refer to the configuration to learn the path without knowing how
the path is chosen themselves.
- The above two would ensure that the configuration would always
exist once a submodule enters our system (and "git submodule init"
is done to cause its gitdir created).
So, unless I am missing some corner case that still exists while
bootstrapping a new style repository with extension, Patrick's
"error when configuration is missing" sounds quite sensible to me.
I am officially still on vacation, so I'd stop here for now ;-).
I guess the one edge case is when somebody manually turns on the
extension after they have already initialized submodules. In that case
the gitdir paths would of course not exist in the gitconfig. But I think
blindly falling back to a source of truth different than the
configuration is wrong, as it would mean that the we have "a single
source of truth unless we don't". It would kind of defeat the whole
purpose of the extension in my opinion, as implementations cannot rely
on it.
Maybe the right approach would be to tell users to never manually enable
the extension and instead to provide a command that both:
- Persists the submodule gitdirs for any populated submodules in the
gitconfig.
- Enables the repsitory extension.
If we had that then we could count on the submodule gitdirs to exist in
the gitconfig, and if they don't we would die with an error message that
indicates that the repository is broken, maybe even with a hint for the
user on how to fix it.
Patrick
On Sat, 06 Dec 2025, Patrick Steinhardt [off-list ref] wrote:
On Sat, Dec 06, 2025 at 07:47:56AM +0900, Junio C Hamano wrote:
quoted
Adrian Ratiu [off-list ref] writes:
quoted
quoted
It feels somewhat fragile to me that we unconditionally handle these
cases and try to find old submodule directories. If the extension is
enabled I'd expect that the submodule configuration is the _only_ source
of truth.
May I propose that we instead always error out in case the submodule
configuration does not exist? In the best case we'd then give the user a
nice error message that tells them how to run the migration manually.
Junio told me to not do any kind of manual migration and just attempt
new names until one works and then use it consistently.
Indeed, but I do not think that has much relevance to Patrick's
comment. What I meant say was
- With extension, we know that the repository will use the
configuration item as the sole source of truth. Unlike the "we
now store submodule dirs to munged paths" design that we saw long
ago, which would have required us to sometimes move the existing
directories to match the munging scheme, we do not have to
manually migrate the existing directories. Instead, we can just
record the pathnames they already use.
- And with extension, when we add a new submodule, we would need to
give them an entry in the configuration that does not conflict
with those used by the existing submodules. As Patrick mentions,
this name does not have to be done with any reversible mapping,
and third-party software and Git reimplementations can always
refer to the configuration to learn the path without knowing how
the path is chosen themselves.
- The above two would ensure that the configuration would always
exist once a submodule enters our system (and "git submodule init"
is done to cause its gitdir created).
So, unless I am missing some corner case that still exists while
bootstrapping a new style repository with extension, Patrick's
"error when configuration is missing" sounds quite sensible to me.
I am officially still on vacation, so I'd stop here for now ;-).
I guess the one edge case is when somebody manually turns on the
extension after they have already initialized submodules. In that case
the gitdir paths would of course not exist in the gitconfig. But I think
blindly falling back to a source of truth different than the
configuration is wrong, as it would mean that the we have "a single
source of truth unless we don't". It would kind of defeat the whole
purpose of the extension in my opinion, as implementations cannot rely
on it.
Haven't thought about it that way and indeed it makes a lot of sense.
100% agreed.
Maybe the right approach would be to tell users to never manually enable
the extension and instead to provide a command that both:
- Persists the submodule gitdirs for any populated submodules in the
gitconfig.
- Enables the repsitory extension.
If we had that then we could count on the submodule gitdirs to exist in
the gitconfig, and if they don't we would die with an error message that
indicates that the repository is broken, maybe even with a hint for the
user on how to fix it.
Thank you Patrick for clarifying this, really appreciate it.
I will implement this design in v6.