All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Sim Tov <smntov@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: "mixed" or "merged" submodules
Date: Wed, 06 Jul 2022 11:16:11 +0200	[thread overview]
Message-ID: <220706.867d4qa9b3.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <CA+X_a+z-=K5BfDpMiWAnnVma6ihh6kUXb84CCrHL5gte5WykMw@mail.gmail.com>


On Tue, Jul 05 2022, Sim Tov wrote:

> Hello,
>
> here  https://stackoverflow.com/q/72770397/1876484
>
> I asked this question:
>
> I'm aware of git submodules which dwell each in its own separate directory.
>
> 1. But is there such thing as "mixed" submodules whose content is
> "merged" together?
>
> For instance:
>
> - Submodule1 (path ./), consist of files `a.txt`, `b.txt` and
> directory `C` with the file `1.txt`
> - Submodule2 (path ./), consist of files `x.txt`, `y.txt` and
> directory `C` with the file `2.txt`
> - Resulting "mixed" repo of both submodules: files `a.txt`, `b.txt`,
> `x.txt`, `y.txt` and directory `C` with the files `1.txt`, `2.txt`
>
> 2. If it is not implemented in git - is there a workaround to achieve this?
>
> Here my use case:
>
> Both submodules - independent libraries (collection of books as plain
> text files), which have same structure (directories = book
> categories). I want to present the combined parent git repository as
> full collection of books, while both projects evolve independently and
> do not overlap (in terms of file names = books).
>
> I got a very detailed and informative answer. My question now - do you
> see any other practical use cases for such a feature? Would such a
> more general case of submodules be a good feature in git or not?

Good question, but to answer the thought experiment don't conflate
submodules with this, instead suppose that you have two branches A & B,
which have:

    A: A.txt
    B: B.txt

How will you create and maintain a third branch C which has the union of
the two?

The answer to that question will be the same as with the submodule case,
i.e. you'd need to have some third branch that you maintain (e.g. with a
push hook?) that would be a merge of the two, and ensure that you don't
have path conflicts there.

Then if you wanted to use such a branch as a submodule you'd grab that
down like you would any other branch.


  reply	other threads:[~2022-07-06  9:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-05 20:35 "mixed" or "merged" submodules Sim Tov
2022-07-06  9:16 ` Ævar Arnfjörð Bjarmason [this message]
2022-07-06 12:28   ` Sim Tov

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=220706.867d4qa9b3.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=smntov@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 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.