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".
>> +-i, --init::
>> + Initialize the specified submodules, i.e. clone the git repository
>> + specified in .gitmodules and checkout the sha1 specified in the
>> + index.
>
> How about "Initialize the submodules...", and then another sentence "If
> you do not want to initialize all submodules, you can specify the subset
> to initialize"?
>> +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
>> +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. 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.
-
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
