git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Jeff King'" <peff@peff.net>, "'Junio C Hamano'" <gitster@pobox.com>
Cc: "'Lukas Straub'" <lukasstraub2@web.de>,
	"'git'" <git@vger.kernel.org>,
	"'Elijah Newren'" <newren@gmail.com>,
	"'Brandon Williams'" <bwilliams.eng@gmail.com>,
	"'Johannes Schindelin'" <Johannes.Schindelin@gmx.de>
Subject: RE: [RFC PATCH 0/2] Allow adding .git files and directories
Date: Wed, 19 Aug 2020 17:56:18 -0400	[thread overview]
Message-ID: <04e401d67673$94c47d30$be4d7790$@nexbridge.com> (raw)
In-Reply-To: <20200819203825.GA2511902@coredump.intra.peff.net>

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.



  reply	other threads:[~2020-08-19 21:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-19 16:43 Lukas Straub
2020-08-19 16:43 ` [RFC PATCH 1/2] dir/read-cache: " Lukas Straub
2020-08-19 16:43 ` [RFC PATCH 2/2] dir: Recurse into nested git repos if they aren't submodules Lukas Straub
2020-08-19 18:03 ` [RFC PATCH 0/2] Allow adding .git files and directories Junio C Hamano
2020-08-19 18:47   ` Randall S. Becker
2020-08-19 19:09     ` Junio C Hamano
2020-08-19 19:23       ` Randall S. Becker
2020-08-19 20:17       ` Jeff King
2020-08-19 20:32         ` Junio C Hamano
2020-08-19 20:38           ` Jeff King
2020-08-19 21:56             ` Randall S. Becker [this message]
2020-08-20 10:16             ` Johannes Schindelin
2020-08-20 11:34             ` Lukas Straub
2020-08-20 13:01               ` Jeff King
2020-08-21 12:39                 ` Lukas Straub
2020-08-21 13:11                   ` Randall S. Becker
2020-08-21 22:52                   ` brian m. carlson
2020-08-22 14:21                     ` Lukas Straub
2020-08-22 18:53                       ` brian m. carlson
2020-08-22 19:12                         ` Lukas Straub
2020-08-24 13:52                           ` Johannes Schindelin
2020-08-20 12:37         ` Lukas Straub
2020-08-20 13:08           ` Jeff King
2020-08-19 19:22     ` Lukas Straub
2020-08-19 18:47   ` Lukas Straub
2020-08-19 19:16     ` Randall S. Becker
2020-08-20 11:46       ` Lukas Straub

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='04e401d67673$94c47d30$be4d7790$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=bwilliams.eng@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=lukasstraub2@web.de \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --subject='RE: [RFC PATCH 0/2] Allow adding .git files and directories' \
    /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

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).