On 5/25/07, Junio C Hamano <junkio@xxxxxxx> wrote:
Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> On Fri, 25 May 2007, Lars Hjemli wrote:
>
>> Btw: testing this quickly becomes tedious, so I'll try to make a proper
>> testscript later tonight.
>
> Very good.
>
>> +'git-submodule' [--init | --update | --cached] [--quiet] [--] [<path>...]
>
> I did not realize this earlier, but we seem to have more and more programs
> where actions are specified without "--", i.e. "git-svn fetch", or
> "git-bundle create".
>
> I actually like that, to separate actions from options. Hmm?
I think it is a sensible thing to do for this kind of "wrapper
of different functionalities related to one area".
Ok, there seems to be general agreement on this, so how about
something like this instead:
git-submodule [--quiet] [--cached] [init | update] [--] [<path>...]
or would you rather have
git-submodule [--quiet] [--cached] <cmd> [<path>...]
with cmd being one of init, update, status?
>> +FILES
>> +-----
>> +When cloning submodules, a .gitmodules file in the top-level directory
>> +of the containing work-tree is examined for the url of each submodule.
>> +The url is the value of the key module.$path.url.
>
> IIRC Junio talked about a name for overriding. But I think it would be
> even better to to override by mapping the URLs from .gitmodules to the
> locally-wanted URLs.
>
> Junio?
I really do not want that (mis)conception that .gitmodules
specify the default and .git/config the override. I really
think we should use the .git/config as _the_ only authority to
get URL, but keyed with the three-level scheme, with URL in
.gitmodules used _solely_ as a hint when setting up the URL in
the .git/config file.
cf. $gmane/47502, 47548, 47621
I've read these articles, but I think much of the concerns about
trusting the url supplied by upstream goes away when the submodule
clone/checkout isn't an integrated part of the superproject
clone/checkout. Besides, if you trust your upstream enough to clone
their repository (the superproject), why wouldn't you trust the data
(.gitmodules) in that very repository?
Still, a way to locally override the suggested url is probably needed.
This can be easily achieved by either yours or Linus' suggestion
about 'url rewriting'. And if clone/checkout doesn't touch the
submodules at all, the downstream user can look at/override the
.gitmodules file in his local tree before deciding to do the submodule
clone or checkout. I don't think there is any need for an interactive
tool here.
Another possibility is simply doing the submodule clone/checkout by
hand (i.e. do 'git clone preferred-url path', don't do 'git submodule
init path').
>> +When updating submodules, the same .gitmodules file is examined for a key
>> +named 'module.$path.branch'. If found, and if the named branch is currently
>> +at the same revision as the commit-id in the containing repositories index,
>> +the specified branch will be checked out in the submodule. If not found, or
>> +if the branch isn't currently positioned at the wanted revision, a checkout
>> +of the wanted sha1 will happen in the submodule, leaving its HEAD detached.
>
> A very good description, and I think this is the only method to checkout
> the submodule which makes sense. (Just maybe default the value of
> module.<path>.branch to "master"?)
I suspect leaving the HEAD always detached if the superproject
tree names a concrete commit object name would be less confusing
and consistent.
And easier to explain :)
When the name of the commit object in the
superproject tree and/or index is 0{40}, it would be a good
extension to use "whatever commit that happens to be at the tip
of this branch" taken from the .gitmodules file.
I really can't imagine what kind of superproject would have such a
setup. Why would this be needed?
--
larsh
-
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
