On 09/26, Junio C Hamano wrote: > Brandon Williams <bmw...@google.com> 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 ;-)
No worries, I'm still trying to get a hang of all this :) True, that wouldn't be completely hidden either. > > 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
