On Tue, Mar 19 2019, Jeff King wrote: > On Sat, Mar 09, 2019 at 10:46:09AM +0000, Dimitri Joukoff wrote: > >> Thus, this feature request is asking that the 'pre-receive' hook >> triggers when someone tries to push to a repository regardless of >> whether the repository exists. This would allow automatic creation of >> new repositories and smooth the work-flow described above. If the >> semantics of the existing 'pre-receive' hook are such that it would not >> be suitable for such a purpose, then an alternative way of providing the >> call-back ability would be implemented. > > The pre-receive hook is a bit too late for this. It runs after the > server has told the client what it has in the repo, the client decides > what to push, and the server has received the pack. So receive-pack > would have to know about this and fake having an empty repository. And > then figure out where to store the incoming packfile, since we have no > repo. > > So I think it would have to be another hook that runs before the rest of > receive-pack. I.e., a system-level config option that says "if you are > asked to accept a push for a repo and it doesn't exist, run this instead > and then run as usual". > > It does feel a little error-prone, though, if the client does not > positively say "I want you to create this if it doesn't exist". > Otherwise if I do "git push server:my-misspelled-repo.git", the result > is going to be rather confusing. And retro-fitting that into the > receive-pack protocol is going to be tricky. > > It would be much easier to have a separate endpoint for the client to > say "please make this repo if it doesn't exist". And then just run that > before doing the push. > > For an unrestricted client connecting over ssh, we already have that: > you can just run "ssh $host git init /path/to/repo". There isn't a > similar thing that can be done over HTTP, though. Sounds simpler to just change the user's login shell to a wrapper that checks if the repo exists, and if not create it before proceeding. The same with http(s). I.e. in whatever webserver that's now pointing to git-http-backend as a script point to the same wrapper script.
