On Wed, 19 Aug 2020 16:38:25 -0400
Jeff King <peff@peff.net> 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
> 
> etc. I think this is really a solution in search of a problem.
> 
> -Peff

Yes, there are many workarounds and they work well in the CI usecase. However,
for the arbitrary files usecase there is no good workaround. I currently use
a script which iterates over the tree and renames .git -> dotgit before running
any git command and back again afterwards, but it is slow and brittle. I toyed
with the idea of writing a FUSE filesystem to do the renaming, but it is
needlessly complex and hurts performance.

Really, this problem should be solved in git itself.

Regards,
Lukas Straub