Jeff King <peff@xxxxxxxx> writes: > Yeah, I agree that all of the mechanisms for dealing with the unrelated > history are somewhat awkward. Another issue is that you can't just: > > git clone --single-branch -b refs/ci/config my-config > > to work on it, because "-b" wants only heads or tags (we could address > that by putting it in refs/heads/ci-config or similar). I somehow don't think that it is such a huge issue, because I expect anybody who has legitimate interest in refs/ci/config to have a full clone of git.git anyway. So it is more like defining another remote.origin.fetch like this: [remote "origin"] url = https://git.kernel.org/pub/scm/git/git.git/ fetch = +refs/heads/*:refs/remotes/origin/* + fetch = +refs/ci/config:refs/remotes/origin/ci-config [remote "publish"] url = https://github.com/user/git/ and then do something like: $ git worktree add -b ci-config ../git-ci-config origin/ci-config $ cd ../git-ci-config ... hack hack hack ... $ git push publish ci-config:refs/ci/config > If we do go the javascript route, perhaps it would make sense for > refs/ci/config to be a single blob containing a snippet of javascript > with several functions. And then we could just eval() that and call the > appropriate functions (if defined). Yup. > Then a sample can live in the main repo with something like: > > # This file contains functions which will be run by the GitHub > # Actions CI script. > # > # You may customize it for your own fork by modifying it on any branch > # you like, and installing with: > # > # git push <remote> $(git rev-parse HEAD:ci/config):refs/ci/config > # > # [allow_ref() sample definition and documentation....] > > That sidesteps most of those issues. Perhaps.
