git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: "Coiner, John" <John.Coiner@amd.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: git, monorepos, and access control
Date: Thu, 6 Dec 2018 21:08:45 +0100 (STD)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1812062100020.41@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20181205210104.GC19936@sigill.intra.peff.net>

Hi,

On Wed, 5 Dec 2018, Jeff King wrote:

> The model that fits more naturally with how Git is implemented would be
> to use submodules. There you leak the hash of the commit from the
> private submodule, but that's probably obscure enough (and if you're
> really worried, you can add a random nonce to the commit messages in the
> submodule to make their hashes unguessable).

I hear myself frequently saying: "Friends don't let friends use
submodules". It's almost like: "Some people think their problem is solved
by using submodules. Only now they have two problems."

There are big reasons, after all, why some companies go for monorepos: it
is not for lack of trying to go with submodules, it is the problems that
were incurred by trying to treat entire repositories the same as single
files (or even trees): they are just too different.

In a previous life, I also tried to go for submodules, was burned, and had
to restart the whole thing. We ended up with something that might work in
this instance, too, although our use case was not need-to-know type of
encapsulation. What we went for was straight up modularization.

What I mean is that we split the project up into over 100 individual
projects that are now all maintained in individual repositories, and they
are connected completely outside of Git, via a dependency management
system (in this case, Maven, although that is probably too Java-centric
for AMD's needs).

I just wanted to throw that out here: if you can split up your project
into individual projects, it might make sense not to maintain them as
submodules but instead as individual repositories whose artifacts are
uploaded into a central, versioned artifact store (Maven, NuGet, etc). And
those artifacts would then be retrieved by the projects that need them.

I figure that that scheme might work for you better than submodules: I
could imagine that you need to make the build artifacts available even to
people who are not permitted to look at the corresponding source code,
anyway.

Ciao,
Johannes

  parent reply	other threads:[~2018-12-06 20:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-05 20:13 git, monorepos, and access control Coiner, John
2018-12-05 20:34 ` Ævar Arnfjörð Bjarmason
2018-12-05 20:43   ` Derrick Stolee
2018-12-05 20:58     ` Duy Nguyen
2018-12-05 21:12       ` Ævar Arnfjörð Bjarmason
2018-12-05 23:42         ` Coiner, John
2018-12-06  7:23           ` Jeff King
2018-12-05 21:01 ` Jeff King
2018-12-06  0:23   ` brian m. carlson
2018-12-06  1:08   ` Junio C Hamano
2018-12-06  7:20     ` Jeff King
2018-12-06  9:17       ` Ævar Arnfjörð Bjarmason
2018-12-06  9:30         ` Jeff King
2018-12-06 20:08   ` Johannes Schindelin [this message]
2018-12-06 22:15     ` Stefan Beller
2018-12-06 22:59     ` Coiner, John
2018-12-05 22:37 ` Ævar Arnfjörð Bjarmason

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1812062100020.41@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=John.Coiner@amd.com \
    --cc=git@vger.kernel.org \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).