From: Junio C Hamano <gitster@pobox.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>, Duy Nguyen <pclouds@gmail.com>,
Jeff King <peff@peff.net>
Subject: Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
Date: Sun, 14 Apr 2013 19:48:47 -0700 [thread overview]
Message-ID: <7v61zo4igg.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7vy5ck4m6b.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Sun, 14 Apr 2013 18:28:28 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> If the envisioned use of this is to use it as a building block of
> something else that is user-facing (e.g. the user says "git add",
> and before the command finishes, somewhere we internally run "git
> clone"), then would it be possible that you are better off running
> that clone with --separate-git-dir and let it make the gitfile for
> you?
As you may have already guessed, in principle I am all for teaching
"git add" not just to add a submodule itself (which we already do)
but also to record information about the submodule, without having
to delegate it to "git submodule". "git submodule add" was meant as
an interim measure until we figure out what kind of metainformation
is necessary, and doing things in "git add" has always been a longer
term goal.
There are two ways to "add" a submodule to a superproject. You may
bring an existing project with "git clone" inside the working tree
of a superproject (which I am guessing is the use case that inspired
this patch), but it will leave the git dir of the submodule embedded
in its working tree.
You could continue "git clone" and then teach "git add" (or "git
submodule add") to relocate the embedded git directory from the
submodule working tree, you could "git clone" with separate-git-dir
from the beginning, or you could extend "git add", perhaps
git add --url=git://up.stre.am/repository [--name=name] sub/mod/ule
and do that "git clone --separate-git-dir" internally (which will
mean that the end user will not run "git clone").
Another way ti "add" a submodule is to run "git init" to originate a
new project inside the working tree of a superproject. The resulting
submodule working tree will have the embedded git dir, and again
"git add" (or "git submodule add") could notice and relocate it, but
if the extended "git add" wants to help that use case as well, I
think it is the matter of running "git init --separate-git-dir",
just like "add by cloning from elsewhere" can do the same with the
flag to "git clone".
next prev parent reply other threads:[~2013-04-15 2:49 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-13 19:23 [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR Ramkumar Ramachandra
2013-04-15 1:28 ` Junio C Hamano
2013-04-15 2:48 ` Junio C Hamano [this message]
2013-04-15 8:08 ` Ramkumar Ramachandra
2013-04-15 10:14 ` Junio C Hamano
2013-04-15 11:35 ` Ramkumar Ramachandra
2013-04-15 7:59 ` Ramkumar Ramachandra
2013-04-15 8:19 ` Ramkumar Ramachandra
2013-04-15 9:25 ` Duy Nguyen
2013-04-15 9:47 ` Ramkumar Ramachandra
2013-04-15 9:45 ` Junio C Hamano
2013-04-15 11:48 ` Ramkumar Ramachandra
2013-04-15 15:50 ` Marc Branchaud
2013-04-15 17:50 ` Junio C Hamano
2013-04-15 18:00 ` Ramkumar Ramachandra
2013-04-15 18:43 ` Jeff King
2013-04-15 20:52 ` Junio C Hamano
2013-04-16 8:13 ` Ramkumar Ramachandra
2013-04-16 15:39 ` Marc Branchaud
2013-04-15 18:50 ` Marc Branchaud
2013-04-16 8:17 ` Ramkumar Ramachandra
2013-04-16 15:46 ` Marc Branchaud
2013-04-15 18:43 ` Marc Branchaud
2013-04-15 18:50 ` Junio C Hamano
2013-04-15 20:32 ` Marc Branchaud
2013-04-15 20:56 ` Junio C Hamano
2013-04-16 8:21 ` Ramkumar Ramachandra
2013-04-16 15:46 ` Marc Branchaud
2013-04-15 17:50 ` Ramkumar Ramachandra
2013-04-16 2:58 ` Jonathan Nieder
2013-04-16 8:36 ` Ramkumar Ramachandra
2013-04-16 17:28 ` Junio C Hamano
2013-04-17 15:48 ` Jonathan Nieder
2013-04-17 10:22 ` Duy Nguyen
2013-04-17 10:53 ` Ramkumar Ramachandra
2013-04-17 10:59 ` Duy Nguyen
2013-04-17 11:13 ` Ramkumar Ramachandra
2013-04-17 11:36 ` Duy Nguyen
2013-04-17 15:02 ` Ramkumar Ramachandra
2013-04-17 23:01 ` Duy Nguyen
2013-04-17 17:18 ` Junio C Hamano
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=7v61zo4igg.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
/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).