>> We find this mechanism useful in that it requires no extra >> infrastructure on either our end or the user's end. Our >> implementation is extensible, allowing the system administrator to >> place arbitrary commands in ~/git-shell-commands (if the directory is >> omitted, no extra functionality is exposed), and also supports an >> interactive mode. >> >> What do people think of this approach? I'd love to get this >> functionality merged in some form. > > It seems to me that any time you need to add a new helper command, the > administrator needs to make sure that appears in ~$user/git-shell-commands > of all the users who need it. When adding a new user, a similar > management action needs to happen. Perhaps that is done by making a > symlink from all the users' home directories to one shared place. Is that > the general idea? That's correct. Our particular environment only has a single git user, but if we were to add more we would probably make git-shell-commands a symlink as you suggest. > In any case, I'd prefer that the sample command implementations like list > and help to live in contrib/ somewhere. They are not part of what the > main Makefile needs to know about, right? Also correct. I'll look for a reasonable place within contrib/ to put them. -- 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