"Alexander Gavrilov" <angavrilov@gmail.com> writes:

quoted text
> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html