On Tue, Apr 22, 2008 at 6:03 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Here are the topics that have been cooking. Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
>
>
> * py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit
> - git-submodule: Extract functions module_info and module_url
>
>
> I only managed to queue the first one so far.
>
> It does not help motivating me reviewing the series that the overall tone
> of it is to ignore .git/config more and make .gitmodules take more active
> role, either. I have already said number of times why that is not a good
> idea and why it is against the overall submodule design.
I summarize junio's points that says $GIT_DIR/config is authoritative.
1. .gitmodules shouldn't be authoritative and should be just a hint
to fill $GIT_DIR/config because
a) url may be rewritten with different protocol, such as from
"http://"; to "git://"
b) url may be total different between .gitmodules and
$GIT_DIR/config
2. When going back to an old HEAD of super project and do
"git submodule update", the url recorded in .gitmodules may be
stale or not existent anymore, so we should refer to
$GIT_DIR/config for the right url.
3. We can record what contents we've seen in the .gitmodules, so that
we can give users a chance to adjust what is in $GIT_DIR/config
when we notice the entry in .gitmodules has changed.
Any others?
However, i argue the fall back strategy (say fall back to .gitmodules
when we can't find an entries in $GIT_DIR/config) doesn't break the
authority and isn't in contrast with the cases above. It just attachs
more importance to .gitmodules and can make the world better in most
cases.
For 1.a, i think we can keep these entries in .gitmodules, and use
"url.<thisurl>.insteadof = <otherurl>" to override the urls.
For 1.b, i think this is a rare case. And we can override these urls
in $GIT_DIR/config. However, in many cases, we havn't to do that.
For 2, i think it is also a rare case. And before going back, we can
override the urls in $GIT_DIR/config.
For 3, i havn't found a good way to do that. And it doesn't conflict
with the fall back strategy (say, wh
So, my conclusion
* 1.b, 2 and 3 are all rare cases, and these cases don't conflict with
the fall back strategy
* 1.a is a usual case, and fallback + 'url insteadOf" will make things
better
* The most common case is that most (even all) entries in .gitmodules
are the same as entires in $GIT_DIR/config. So with fallback, we
don't have to copy entries from .gitmodules to $GIT_DIR/config.
* And, in a central environment, i think it's common that the super
project and sub project use the same protocol. So if we use relative
urls in .gitmodules, when changing the url protocol the super
project, the urls in .gitmodules needn't change and can be
dynamically expanded with the url of the super project (Of course,
after applying the 2nd patch of this series)
--
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
