On Tue, Apr 22, 2008 at 10:38 PM, Ping Yin <pkufranky@xxxxxxxxx> wrote:
> > > Please have that kind of justification in the proposed commit log message.
> > > When these changes are made into history, people cannot ask you questions
> > > like I did and expect the history to produce such answer on demand ;-)
> > >
> >
> > OK, i'll resend this patch tonight.
>
> See attached patch
Only the commit message changes.
git-submodule: Fix inconsistent handling of relative urls with './' prefix
There is a little inconsistence in current handling of relative url
with "./"
- "git submodule add ./foo" will clone the submodule with url
"${remote.origin.url}/foo" and init an entry 'submodule.foo.url=./foo"
in .gitmodules
- "git submodule init" will init an entry in $GIT_DIR/config as
"submodule.foo.url=${remote.origin.url}/foo"
- However, if there is an entry "submodule.foo.url=./foo" in
$GIT_DIR/config, "git submodule update" will not expand
"./foo" with remote.origin.url
This patch unifies the behaviour of handling relative urls with './'
prefix. Now "git submodule init" copies urls from .gitmodules to
$GIT_DIR/config as is without expanding. And the url expanding happens
only at runtime, say when "git submodule add" or "git submodule update".
absolute_url is extracted to remove code redundance and fix inconsistence
in cmd_init and cmd_add when resolving relative url/path to absolute one.
Also move resolving absolute url logic from cmd_add to module_clone which
results in the expected behaviour change: cmd_update will resolve url
'./foo' in $GIT_DIR/config as "${remote.origin.url}/foo" instead of
"$(pwd)/foo".
This behaviour change breaks t7400 which uses relative url './.subrepo'.
However, this test originally doesn't mean to test relative url with './'
prefix, so fix the url as '.subrepo'.
--
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
