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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.