Brandon Williams [off-list ref] writes:
In a previous email you mentioned that this feature should be completely
hidden from users, which is why I removed the command line option for
this latest series.
I may have said something like that; I do not recall, though, so a
more accurate description might be "I may have said something that
can be (mis)interpreted like so". Sorry for the confusion.
In any case, an environment is not "completely hidden from users",
so it is not fundamentallly different from a command line option
anyway ;-)
If that isn't what you intended that I can
definitely add the option to git.c. And you would rather we perform the
checking in git.c to see if a subcommand supports the prefix versus
silently ignoring it if it hasn't? I'm assuming this checking would
also be done in git.c?
I actually do not care strongly _where_ the check happens. It was
just that in the subcommand dispatcher would be the single place
that is easiest-to-implement to perform that check, that made me
suggest that. We already have various bits like NEEDS_WORK_TREE,
RUN_SETUP, etc. so REJECT_EXTERNAL_PREFIX (or whatever its name be;
I do not offhand recall current proposal) bit would fit there
naturally, I would think. Of course, non-built-in commands need to
protect themselves separately, if they want to.
On 09/26, Junio C Hamano wrote:
Brandon Williams [off-list ref] writes:
quoted
In a previous email you mentioned that this feature should be completely
hidden from users, which is why I removed the command line option for
this latest series.
I may have said something like that; I do not recall, though, so a
more accurate description might be "I may have said something that
can be (mis)interpreted like so". Sorry for the confusion.
In any case, an environment is not "completely hidden from users",
so it is not fundamentallly different from a command line option
anyway ;-)
No worries, I'm still trying to get a hang of all this :)
True, that wouldn't be completely hidden either.
quoted
If that isn't what you intended that I can
definitely add the option to git.c. And you would rather we perform the
checking in git.c to see if a subcommand supports the prefix versus
silently ignoring it if it hasn't? I'm assuming this checking would
also be done in git.c?
I actually do not care strongly _where_ the check happens. It was
just that in the subcommand dispatcher would be the single place
that is easiest-to-implement to perform that check, that made me
suggest that. We already have various bits like NEEDS_WORK_TREE,
RUN_SETUP, etc. so REJECT_EXTERNAL_PREFIX (or whatever its name be;
I do not offhand recall current proposal) bit would fit there
naturally, I would think. Of course, non-built-in commands need to
protect themselves separately, if they want to.
That makes sense. I have an idea of where the check could be made. And
with those flags it may make sense to have the flag be an indicator that
the builtin is ready for submodule type commands ie SUPPORTS_SUBMODULES
or something along those lines. That way we only need to add the flag
to each command as we go (instead of all commands which don't support
it) and just make sure that the flag is set if the submodule prefix
option is being used. How does that sound?
--
Brandon Williams