Re: using .gitmodule as default (was: git submodule init and redundant data in .gitmodules/.git/config)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday 16 August 2007, martin f krafft wrote:
> also sprach Sven Verdoolaege <skimo@xxxxxxxxxx> [2007.08.15.1838 +0200]:
> > The (most appropriate) URL from which to get updates of a submodule
> > may be different for different people and therefore has to be stored
> > in .git/config.  It was then decided that the default value
> > for this URL should be stored in .gitmodules.  git submodule init
> > simply initializes the URL using this default value.  You are free
> > to not call git submodule init and set a (more) appropriate URL manually.
> 
> Ah. I shall prepare a patch against the manpage to make this more
> clear then. Thanks for your explanation.
> 
> I have one open question though: why require init? It makes perfect
> sense to allow for a local override, but unless I need to override
> it, git-submodule update should really just keep using the default,

The information in .gitmodules is only a default value for the URL,
and not to be actually used. The URL in the config has to exist and
will be used for updating. So the config value is not about overriding
anything, but is required information.

The URL should not depend on the current revision you have checked out
at the moment; otherwise, if the default URL in .gitmodules changed at
some point in the history, and you check out some earlier commit in the
superproject, the update of the submodule would not work: the
submodule project still resides on the new URL, regardless of the old
information in .gitmodules at the time of the old commit.

Josef
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux