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

From: Jeff King <peff@peff.net>
Date: Aug 19, 2020, 20:38 UTC
Message-ID: <20200819203825.GA2511902@coredump.intra.peff.net>
In-Reply-To: <xmqqa6yqtm03.fsf@gitster.c.googlers.com>

On Wed, Aug 19, 2020 at 01:32:28PM -0700, Junio C Hamano wrote:

Show 18 quoted lines

> 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