From: Junio C Hamano <gitster@pobox•com>
To: "Lauri Alanko" <la@iki•fi>
Cc: git@vger•kernel.org
Subject: Re: A design for subrepositories
Date: Sat, 13 Oct 2012 10:30:00 -0700 [thread overview]
Message-ID: <7vd30m2sbr.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20121013163322.685276teuhqhjc82.lealanko@webmail.helsinki.fi> (Lauri Alanko's message of "Sat, 13 Oct 2012 16:33:22 +0300")
"Lauri Alanko" <la@iki•fi> writes:
> I intend to work on a "subrepository" tool for git, but before I
> embark on the actual programming, I thought to first invite comments
> on the general design.
>
> Some background first. I know that there are several existing
> approaches already for managing nested repositories, but none of them
> quite seems to fit my purposes. My primary goal is to use git for home
> directory backup and mirroring, while the home directory itself may of
> course contain repositories.
> ...
> Submodules are a bit closer to what I want, but they have clearly been
> designed for a different purpose: a repository with submodules is only
> supposed to collate existing repositories, not act as a source for
> them.
I have a repository that covers my home directory and some of its
subdirectories have their own repositories.
I had my home directory and its subdirectories before Git ever
existed, and I made my home directory and these subdirectories into
separate, nested Git repositories fairly early after I started
managing them with Git---way before submodules were invented. Now
the subdirectory repositories are bound as submodules of the top
level directory just fine.
I push these out for safekeeping purposes, all of my machines get
their copies from here, and some submodules are not cloned to work
machines (they house data of private nature). They are used just
like you are expected to use submodules. In fact, this is pretty
much vanilla use case of submodules, I think.
They _all_ originate from under my home directory, not "collating
existing repositories" at all.
Have you considered how you can _extend_ submodules support to
support your use case better? I think that would be a much more
useful approach, as you are likely to get help from other people who
do use submodules.
next prev parent reply other threads:[~2012-10-13 17:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-13 13:33 A design for subrepositories Lauri Alanko
2012-10-13 17:30 ` Junio C Hamano [this message]
2012-10-13 21:23 ` Lauri Alanko
2012-10-14 4:36 ` Junio C Hamano
2012-10-14 10:19 ` Lauri Alanko
2012-10-14 13:28 ` Jens Lehmann
2012-10-14 15:27 ` Lauri Alanko
2012-10-14 16:10 ` Jens Lehmann
2012-10-14 16:15 ` Jens Lehmann
2012-10-14 16:25 ` Jens Lehmann
2012-10-14 18:04 ` Junio C Hamano
2012-10-14 19:32 ` Jens Lehmann
2012-10-19 0:31 ` A design for distributed submodules Lauri Alanko
2012-10-19 20:09 ` Jens Lehmann
2012-10-14 22:59 ` A design for subrepositories Lauri Alanko
2012-10-15 17:10 ` Jens Lehmann
2012-10-13 21:20 ` perryh
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=7vd30m2sbr.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=la@iki$(echo .)fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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