git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).