git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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 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).