Re: git branch --edit-description a custom file

[Jeff King <peff@peff.net>]

On Thu, Oct 31, 2019 at 10:35:07AM -0700, Denton Liu wrote:

> > You could also have "refs/meta/descriptions" to point to a _single_ blob
> > with all of the descriptions. It could even be in the existing config
> > format. And then you could include it with "[include] blob = ...". That
> > doesn't exist yet, but it would be easy to add (it was something I had
> > always considered when writing the config-include code, but there was
> > never really a good use; and you do have to be careful about pointing to
> > untrusted blobs). That's a convoluted way to get where you want, but I
> > wonder if integrating to the existing config system would have any
> > benefits. I haven't really thought it through.
> 
> I like the ability to include blobs for several reasons:
> 
> Main one is that it handles the versioned branch description problem.
> But it goes further than that, there are a lot of config properties that
> teams might want to share amongst each other. For example, whenever a
> project has a custom smudge filter, usually they include some sort of
> config in the project's README or some sort of setup script. With some
> way to include a shared version of some config, this might be simpler.

There are some past discussions on sharing config, and the security
issues around it. The crux of it is that you probably ought to be
vetting config you get from elsewhere (because it can execute arbitrary
code). At which point being able to refer to a blob isn't all _that_
useful, because these two processes are not all that different:

  git show origin/meta:shared-config
  # ok, looks good; _don't_ just include it by that name, though,
  # because it may be updated by a fetch
  git branch -f meta origin/meta
  git config include.blob meta:shared-config

  git show origin/meta:shared-config
  # ok, looks good
  git cat-file blob origin/meta:shared-config >.git/shared-config
  git config include.path shared-config

There's a specific discussion I'm thinking of which goes into this line
of thinking, but I'm having trouble finding it in the archive. But IIRC,
the conclusion was negative towards directly including the blob because
it doesn't make life better for careful users, and it makes it very easy
to be unsafe for non-careful users.

There's also some (negative) discussion in this much older subthread:

  https://public-inbox.org/git/20120126074208.GD30474@sigill.intra.peff.net/

-Peff