"Alexander Gavrilov" <angavrilov@xxxxxxxxx> writes: > Gitosis works by replacing the shell with a program called > gitosis-serve, which parses and validates the incoming commands > against the user access configuration. If it sees an unknown command, > it will simply refuse to execute it. If you implement a new feature by enhancing receive-pack (or anything else), you obviously cannot use the new feature against an installation with an older implementation, so what you said is a known. My point was how to enhance the receiving end and what constraints we would have in enhancing it. > On the other hand it will automatically perform initialization before > calling receive-pack if the user is authorized to write to a certain > path, but the repository does not exist yet. That's good to know. I also realize that gitosis does not need any hook for "git init -D $there" to decide whether a new repository can be created at requested location, as it reads the command line and makes decision before driving the underlying command in response to the request. On the other hand, people who enable 'push' access to their git-daemon would need it, as the daemon would not even know who is asking for --init. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
