From: Marc Branchaud <marcnarc@xiplink.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>,
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: Mon, 15 Apr 2013 14:43:30 -0400 [thread overview]
Message-ID: <516C4A52.1080908@xiplink.com> (raw)
In-Reply-To: <7vvc7nu1hu.fsf@alter.siamese.dyndns.org>
On 13-04-15 01:50 PM, Junio C Hamano wrote:
> Marc Branchaud <mbranchaud@xiplink.com> writes:
>
>> In general I think it is a mistake to overload "git clone" with the notion of
>> adding a submodule.
>
> I agree with that principle, but my understanding is that this
> effort is not about teaching "git clone" to create a submodule.
>
> Both "git clone" and "git init" already know how to use a directory
> that is outside the working tree of the newly created repository to
> store its $GIT_DIR and point at it with .git in the working tree
> using the gitfile mechanism (their --separate-git-dir option). My
> understanding is that this "config" is about making that option
> easier to use when you _know_ any new repository you create with
> "git clone" or "git init" inside your (toplevel super)project's
> working tree will become its submodule, as it is more convenient to
> have their $GIT_DIR inside the .git/modules/$name of the
> superproject.
>
> After that "clone" or "init" creates a repository, you still have to
> "add" if you want to make it a submodule to the toplevel.
To me it makes more sense to move the .git directory when the user invokes
"git submodule add" instead of creating it in an unusual place when the
sub-repo is cloned. After all, git can't *know* that it'll be a submodule
until it's submodule-added to the super-repo. Sure, the user might have set
clone.submoduleGitDir somewhere, but users make mistakes, and this setting
makes it harder to clean up a mistake:
git clone foo.git
# Doh! I mean to clone foof.git!
rm -rf foo
# Gah, now there's cruft in my clone.submoduleGitDir...
All that said, the basic idea of being able to configure where "git clone"
stores .git directories might be reasonable. Something like
clone.gitDirHome. It seems like something only a git hacker would ever care
about, but that's no reason not to have such a config option. OTOH, I still
don't see a reason for it, because I don't buy the submodule-at-clone-time
argument.
M.
next prev parent reply other threads:[~2013-04-15 18:53 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
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 [this message]
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=516C4A52.1080908@xiplink.com \
--to=marcnarc@xiplink.com \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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 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.