On Thu, Mar 6, 2008 at 11:48 AM, Junio C Hamano <gitster@pobox.com> wrote:
quoted text
> "Ping Yin" <pkufranky@gmail.com> writes:
>
>

quoted text
>  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.

quoted text
>
>  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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html