From: Taylor Blau <me@ttaylorr.com>
To: Jeff King <peff@peff.net>
Cc: Adam Majer <adamm@zombino.com>, git@vger.kernel.org
Subject: Re: [PATCH] setup: recognize bare repositories with packed-refs
Date: Fri, 8 Dec 2023 16:09:03 -0500 [thread overview]
Message-ID: <ZXOF75NwxI187QDQ@nand.local> (raw)
In-Reply-To: <20231206210836.GA106480@coredump.intra.peff.net>
On Wed, Dec 06, 2023 at 04:08:36PM -0500, Jeff King wrote:
> On Wed, Nov 29, 2023 at 04:30:46PM -0500, Taylor Blau wrote:
>
> > On Tue, Nov 28, 2023 at 02:04:46PM -0500, Jeff King wrote:
> > > - whatever is consuming the embedded repos could "mkdir -p refs
> > > objects" as needed. This is a minor pain, but I think in the long
> > > term we are moving to a world where you have to explicitly do
> > > "GIT_DIR=$PWD/embedded.git" to access an embedded bare repo. So
> > > they're already special and require some setup; adding an extra step
> > > may not be so bad.
> >
> > I hope not. I suppose that using embedded bare repositories in a test
> > requires additional setup at least to "cd" into the directory (if they
> > are not using `$GIT_DIR` or `--git-dir` already). But I fear that
> > imposing even a small change like this is too tall an order for how many
> > millions of these exist in the wild across all sorts of projects.
>
> I dunno. I am skeptical that there are millions of these. Who really
> wants to embed bare git repos except for projects related to Git itself,
> which want test vectors? Is there a use case I'm missing?
Just picking on GitHub as an example, my copy has a fair number of
embedded bare repositories:
$ find . -mindepth 2 -type d -name '*.git' | wc -l
279
That might be an unfair example in general, since GitHub probably has a
greater need to embed bare repositories than most other projects. But I
think that we shouldn't make our decision here based on volume of
embedded bare repositories, but rather on the number of projects which
have >1 embedded bare repository.
In other words, the cost of migrating a single project's embedded bare
repositories is roughly the same whether there are 1 or 279 of them. So
the effort scales with the number of projects, not repositories.
Perhaps I'm over-estimating how difficult this transition would be to
impose on users. But it does make me very leery to make this kind of a
change without having a better sense of how many of them exist in the
wild.
Searching just on GitHub for `path:**/*.git/config` [^1], it looks like
there are ~1,400 results. That provides us an upper-bound on the number
of projects which have embedded bare repositories, so perhaps I really
am overestimating the burden we'd be imposing on other projects.
I dunno :-).
Thanks,
Taylor
[^1]: Searching for "path:**/*.git" doesn't quite work, since GitHub's
search doesn't match directories here. So the search I actually used
isn't perfect, but it should give us a rough approximation.
next prev parent reply other threads:[~2023-12-08 21:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-17 20:25 [PATCH] setup: recognize bare repositories with packed-refs Adam Majer
2023-11-17 20:32 ` Adam Majer
2023-11-17 20:44 ` Adam Majer
2023-11-19 23:24 ` Junio C Hamano
2023-11-20 9:31 ` Glen Choo
2023-11-27 19:42 ` Josh Steadmon
2023-11-20 9:43 ` Adam Majer
2023-11-27 19:44 ` Josh Steadmon
2023-11-28 14:14 ` Adam Majer
2023-11-28 14:28 ` Adam Majer
2023-11-28 18:45 ` Josh Steadmon
2023-11-28 19:04 ` Jeff King
2023-11-29 10:13 ` Patrick Steinhardt
2023-12-06 20:10 ` Jeff King
2023-12-07 7:01 ` Patrick Steinhardt
2023-12-07 7:34 ` Jeff King
2023-12-07 8:37 ` Patrick Steinhardt
2023-11-29 21:30 ` Taylor Blau
2023-12-06 21:08 ` Jeff King
2023-12-07 8:20 ` Adam Majer
2023-12-08 21:09 ` Taylor Blau [this message]
2023-12-12 1:22 ` Jeff King
2023-12-08 18:17 ` 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=ZXOF75NwxI187QDQ@nand.local \
--to=me@ttaylorr.com \
--cc=adamm@zombino.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.
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.