RFC: snapshot tarball information in refs/notes/snapshots

[john at keeping.me.uk (John Keeping)]

On Fri, Mar 30, 2018 at 11:38:38AM -0400, Konstantin Ryabitsev wrote:
> On Fri, Mar 30, 2018 at 12:53:57PM +0100, John Keeping wrote:
> > Unfortunately there is one big gotcha I encountered doing this, which is
> > that we don't have the repository set up when we are scanning this
> > configuration, because this is done when building the repository list
> > not just for loading repository-specific pages.  Since one of the
> > configuration options is the repository description, I think this is
> > unavoidable.
> 
> One other way I'd thought about doing this is via a post-update hook
> that would read the configuration from an object in the repo into a file
> cgit could read, but I didn't want to write out into .git/config.
> 
> That might be one way of achieving compromise -- support per-repository
> configuration that users themselves can push, but make it up to the
> server administrator to set up hooks so that the config gets written out
> into .git/cgitrc (or repo.git/cgitrc) for cgit to consume. In my mind,
> it was a note attached to the initial commit of the master branch, but
> it can be any object that post-update can access and write out.
> 
> This way cgit doesn't need to rely on git to read this data, as it's a
> regular config file inside the git dir. The post-update hook can also do
> any sanitization of config parameters it deems necessary.
> 
> Does that make sense?

Yes, repo.git/cgitrc is already read unconditionally when using
scan-path to find repositories (under the same conditions as
.git/config).

In a few months, I think it will be possible to pull configuration
directly from objects in the Git repository, but if you want a solution
today then a post-update hook seems like the best way to do it.  As you
say, this also has the advantage that the adminstrator can apply
additional policy to the variables set in the repository.

I don't think notes are the right solution because they tie information
to a particular commit and it's difficult to consistently pick a commit
from which to pull the configuration: anything other than the tip of a
branch will incur the cost of walking to find an annotated commit but
keeping the note at the tip of the branch is difficult and likely to
result in the configuration being lost.

A special ref for configuration is reasonably easy to maintain and if
it's a branch then you can get history attached config file changes for
free.