On Thu, Mar 6, 2008 at 1:48 PM, Ping Yin <pkufranky@xxxxxxxxx> wrote: > 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. It may be not enough. There are many places using code like 'while read name path', and path and name are the same by default, so name and path should use the same name restriction. But path will have slashes and multibyte characters. So how about just limiting name and path not containing whitespace characters? And this should be an implementation restriction. After git-module becomes a builtin, we should cancel the limit. So it should be better to put the naming restriction into git-submodule.sh instead of the document. > > 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 > -- 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
