From: Jonathan Nieder <jrnieder@gmail.com>
To: Craig Silverstein <csilvers@khanacademy.org>
Cc: git@vger.kernel.org, "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: Saving space/network on common repos
Date: Wed, 17 Dec 2014 16:07:23 -0800 [thread overview]
Message-ID: <20141218000723.GP29365@google.com> (raw)
In-Reply-To: <CAGXKyzEqTik3p=A8NZJ6kUscFjw_Dh1mBPT-ciwq9L8kNKDDig@mail.gmail.com>
Craig Silverstein wrote:
> On Wed, Dec 17, 2014 at 2:32 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Craig Silverstein wrote:
>>> Question 4) Is there a practical way to set up submodules so they can
>>> use the same object-sharing framework that the main repo does?
>>
>> It's possible to do, but we haven't written a nice UI for it yet.
>> (In other words, you can do this by cloning with --no-recurse-submodules
>> and manually creating the submodule workdir in the appropriate place.
>
> Hmm, let me see if I understand you right -- you're suggesting that
> when cloning my reference repo, I do
> git clone --no-recurse-submodules <my repo>
> for (path, url) in `parse-.gitmodules`: git clone url path
> # this is psuedocode, obviously :-)
>
> and then when I want to create a new workdir, I do something like:
> cd reference_repo
> git new-workdir /var/workspace1
> for (path, url) in `parse-.gitmodules`: cd path && git new-workdir /var/workspace1/path
>
> ? Basically, I'm going back to the old git way of having each
> submodule have its own .git directory, rather than having it have a
> .git file with a 'gitdir' entry. Am I understanding this right?
Basically. The initial clone can still use --recurse-submodules.
When you create a new workdir you'd create new workdirs for the
submodules by hand.
A 'git submodule foreach' command in the initial repo can take
care of the `parse-.gitmodules` part.
[...]
> Also, it seems to me there's the possibility, with git-newdir, that if
> several of the workspaces try to fetch at the same time they could
> step on each others' toes. Is that a problem? I know there's a push
> lock but I don't believe there's a fetch lock, and I could imagine git
> getting unhappy if two fetches happened in the same repo at the same
> time.
That's a good question. If concurrent fetches cause trouble then I'd
consider it a bug (it's not too different from multiple concurrent
pushes to the same repository, which is a very common thing to do),
but I haven't looked carefully into whether such bugs exist.
Hopefully someone else can chime in.
Thanks,
Jonathan
next prev parent reply other threads:[~2014-12-18 0:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 6:58 Saving space/network on common repos Craig Silverstein
2014-12-17 22:01 ` Stefan Beller
2014-12-17 22:32 ` Jonathan Nieder
2014-12-17 23:57 ` Craig Silverstein
2014-12-18 0:07 ` Jonathan Nieder [this message]
2014-12-23 1:00 ` Craig Silverstein
2014-12-23 1:33 ` Jonathan Nieder
2014-12-23 3:12 ` Jonathan Nieder
2014-12-23 5:36 ` Craig Silverstein
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=20141218000723.GP29365@google.com \
--to=jrnieder@gmail.com \
--cc=csilvers@khanacademy.org \
--cc=git@vger.kernel.org \
--cc=pclouds@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).