On Thu, May 07, 2020 at 11:29:09AM -0700, Junio C Hamano wrote: > 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 I dunno. The duality of refs/ci/config and refs/heads/ci-config is weird. Your two refspecs overlap on their RHS, and once you push up the refs/heads/ci-config you created with "git worktree add", they'll start to conflict (which maybe is OK as long as they're the same). In the patch I sent out a few hours ago I just caved and made refs/heads/ci-config the magic ref, in order to avoid complexity. But it also wouldn't be too bad to say "look, you can store this however you like in refs/heads/ or not at all, but install it into place with git push <remote> HEAD:refs/ci/config". The audience is git.git developers (and even advanced ones whose workflows involve tweaking their CI config), so I'd like to think they could figure it out. I have a feeling that fewer than 5 people in the world will end up using this feature either way. ;) -Peff
