Re: [RFC PATCH 6/6] add: reject nested repositories

> Jeff King <peff@peff.net> writes:
> 
> >>  "	git rm --cached %s\n"
> >>  "\n"
> >> -"See \"git help submodule\" for more information."
> >> +"See \"git help submodule\" for more information.\n"
> >> +"\n"
> >> +"If you cannot use submodules, you may bypass this check with:\n"
> >> +"\n"
> >> +"	git add --no-warn-embedded-repo %s\n"
> >>  );
> >
> > I was a little surprised by this hunk, but I guess if we are going to
> > block the user's operation from completing, we might want to tell them
> > how to get around it. But it seems odd to me that the instructions to
> > "git rm --cached" the submodule remain. If this situation is now an
> > error and not a warning, there is nothing to roll back from the index,
> > since we will have bailed before writing it.
> >
> > If we are going to start recommending --no-warn-embedded-repo here,
> > would we want to promote it from being OPT_HIDDEN_BOOL()? We do document
> > it in the manpage, but just omit it from the "-h" output, since it
> > should be rarely used. Maybe it is OK to stay that way; you don't need
> > it until you run into this situation, at which point the advice
> > hopefully has guided you in the right direction.
> 
> If we are keeping the escape hatch, it would make sense to actually
> use that escape hatch to protect existing "git add" with that,
> instead of turning them into "git submodule add" and then adjust the
> tests for the consequences (i.e. "submodule add" does more than what
> "git add [--no-warn-embedded-repo]" would), at least for these tests
> in [3,4,5/6].