RE: [RFC PATCH 0/2] Allow adding .git files and directories

["Randall S. Becker" <rsbecker@nexbridge.com>]

On August 19, 2020 4:38 PM, Jeff King wrote:
> On Wed, Aug 19, 2020 at 01:32:28PM -0700, Junio C Hamano wrote:
> 
> > Jeff King <peff@peff.net> writes:
> >
> > > It _could_ still be useful in a more isolated environment (e.g.,
> > > your company server that is serving only internal repos to
> > > employees). But I have misgivings about a feature that lets people
> > > intentionally create repositories whose history cannot ever interact
> > > with other users who haven't set a special config flag. It's one
> > > thing to say "to take advantage of this feature, we must all agree
> > > to have version X, or set flag Y". But it's another to bake that
> > > restriction into the repository history for all time.
> >
> > If people want a pre-prepared repository propagated to CI environment
> > and keep trakc of the state of such repository over time, for example,
> > they can use (versioned) tarballs.  Such a tarball won't automatically
> > get extracted after "git pull" (which is a feature), but those who
> > want such a pre-prepared repository for CI can make the extraction
> > step as a part of their CI build procedure.
> 
> Yeah, I almost went into more detail there. There are lots of solutions that
> make accessing an embedded sub-repository only one command away for
> the person who clones. :)  Some others are:
> 
>   - just call it "foo.git", and "mv foo.git .git" solves it (you'd
>     probably want to "git checkout -f" after that, but even if it were
>     embedded it seems silly to hold the data in two separate formats
>     anyway
> 
>   - just hold a bare repository ("foo.git") and then clone it

That is a reasonable approach that will not get you ping'd on the CVE database for someone who wants to do this, which is a key concern of mine.

> etc. I think this is really a solution in search of a problem.