From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Fri, 30 Mar 2018 17:38:29 +0100 Subject: RFC: snapshot tarball information in refs/notes/snapshots In-Reply-To: <20180330153838.GA26612@gmail.com> References: <20180320212336.GA19694@work> <20180321140311.GA10698@work> <20180330115357.GA2287@john.keeping.me.uk> <20180330153838.GA26612@gmail.com> Message-ID: <20180330163829.GC2287@john.keeping.me.uk> 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.