From: Jens Lehmann <Jens.Lehmann@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Lars Hjemli <hjemli@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH RESEND] git submodule add: make the <path> parameter optional
Date: Mon, 05 Oct 2009 12:28:29 +0200 [thread overview]
Message-ID: <4AC9CA4D.7020909@web.de> (raw)
In-Reply-To: <7vtyyek4nz.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> So far, I started submodules by cloning them, doing everything in the
>> other files needed to integrate, and then actually wondered why "git
>> submodule add" could not simply take the (relative) path to the
>> checked-out submodule and deduce the URL from the corresponding config?
>
> Let me try to rephrase the above to see if I understand what you are
> doing. When building a top-level superproject that uses two submodules
> from other places, you would do:
>
> $ git init toplevel
> $ cd toplevel
> $ git clone $overthere submodule1
> $ git clone $elsewhere submodule2
> $ edit Makefile common.h
> $ git add Makefile common.h submodule1 submodule2
>
> and by "the corresponding config", you mean "submodule1/.git/config
> already records that it came from $overthere, and there is no reason to
> say it again in 'git submodule add $overthere submodule1'".
Right, no reason to use git submodule add here. But in this example
submodule1 & submodule2 aren't real submodules, because the .gitmodules
file is not created. Or am i missing something?
> If that is the case, I think it is a very sane argument. It also makes me
> wonder why we need "git submodule add" as a separate step to begin with
> (i.e. "git add" Porcelain could do that behind the scene), but that is
> probably a separate topic.
I think we need git submodule add because it is doing much more than
a plain git add. It also does the clone and creates the .gitmodules
file needed later.
My everyday use case looks different. When i start a new project where
i want to use two of libraries living in their own git repo, i do:
$ git init toplevel
$ cd toplevel
$ git submodule add git://mygitserver/submodule1.git submodule1
$ git submodule add git://mygitserver/submodule2.git submodule2
$ git commit -m 'Initial setup with submodule1 & submodule2'
After the submodule add submodule1, submodule2 and .gitmodules are
added to the index and the two repositories are cloned, so i just
have to do a commit when ready.
And with my patch the two submodule add lines read:
$ git submodule add git://mygitserver/submodule1.git
$ git submodule add git://mygitserver/submodule2.git
Which then resembles the command i would use when i want to clone them
on their own:
$ git clone git://mygitserver/submodule1.git
>> So I would actually vote for making the <repository> parameter optional...
>
> In your "git submodule add submodule1", it would be quite clear that it is
> a local path and <repository> is being omitted. On the other hand, if you
> said "git submodule add $overthere" without submodule1, because $overthere
> is not likely to be an in-tree path, it also would be clear that it is
> omitting the path. IOW, these two typesavers are not mutually exclusive.
>
> In real life, it is very likely $overthere does _not_ end with submodule1,
> and your suggestion would probably be more useful than the patch under
> discussion, I think.
Actually, for me $overthere is _always_ a treeish path (e.g. ends with
submodule1 or submodule1.git). And almost always i have no reason to
name the local directory different than the repo.
Jens
prev parent reply other threads:[~2009-10-05 10:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-22 15:10 [PATCH RESEND] git submodule add: make the <path> parameter optional Jens Lehmann
2009-09-22 19:25 ` Junio C Hamano
2009-10-04 17:51 ` Jens Lehmann
2009-10-04 21:05 ` Johannes Schindelin
2009-10-05 1:31 ` Junio C Hamano
2009-10-05 9:16 ` Johannes Schindelin
2009-10-05 10:28 ` Jens Lehmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AC9CA4D.7020909@web.de \
--to=jens.lehmann@web.de \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hjemli@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).