On Thu, Mar 6, 2008 at 11:48 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Ping Yin" <pkufranky@xxxxxxxxx> writes: > > > I think we are saying the same thing, and I do not understand why you > sound so upset about my comments. I never said it is bad to copy the > "hints" supplied by .gitmodules verbatim to $GIT_DIR/config. > > See how the current cmd_init() uses the information in .gitmodules. It > could later become interactive to allow users to override what's in there, > but by default it simply uses the information from .gitmodules verbatim. > > However, a short-hand to name groups of submodules is not just about > naming one thing with one name, but has user convenience aspect too. > There should be per-user customizability built into the design. You could > probably fix this by making the code first consult $GIT_DIR/config and > then fall back on in-tree .gitmodules file. We agree on this point and 'fall back' is what i will try to do. Our difference is the way to implement it. Since finally we can fall back to .gitmodules when information is not found in .git/config, why always use 'git init' at the first. 'git init' should be useful when a user has many special requirements which can help the user copy info from .gitmodules to .git/config and then edit .git/config. But in many cases (at least in my company), users may not have special requirements, so he needn't use 'git init'. So now 'git init' is not the first class citizen, it's just a util to help users when they need it. And there may be inconsistence between .git/config and .gitmodules when always using 'git init' at first. If .gitmodules has changed in the upstream, what should user do? run 'git init' again? That's not so easy. Since .git/config has a whole copy of .gitmodules, the user has no easy way to know which entries he has changed which shouldn't follow the upstream changes. > > By the way, in your patch, I notice that quoting of $name is often very > loosely done. I do not think we have officially defined what the allowed > repertoire of module name characters are, but we probably should declare > the rules and make sure the code actively enforces it to prevent future > grief. I'd say the same restriction as we have for refnames, except > that we do not allow slashes either, is good enough? > I think it's enough. In this bash script, there are many places which don't/can't handle names containing whitespace well. So the decaring a naming rule for the modue name sounds good. -- Ping Yin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
