On Sun, Jul 29, 2012 at 8:35 PM, Fredrik Gustafsson <iveqy@xxxxxxxxx> wrote: > On Sun, Jul 29, 2012 at 07:55:36PM +0530, Sitaram Chamarty wrote: >> > Thanks, however I think auto-creation is a great feature for some cases >> > and I think there can be even more useable functions if we could get >> > user interaction. >> >> For the record, I don't think I agree. There's a place to create a >> human-conversation, and there's a place not to. >> >> If you want a dialog with the server, there should be *other* commands >> that do that, instead of overloading git's own protocol. >> >> Since you mentioned gitolite, consider copying the fork command >> (src/commands/fork) and munging the code into an explicit wild repo >> create. > > I appriciate that you clearified you oppinion. Please excuse me if it > sounded as I in any way speaked for gitolite. I use gitolite as an > example becuase the target application in this case is unknown to most > people (think gitolite with db-backend for user permissions). > > It's a valid design oppinion to not mix git protocoll with anything > else. But gitolite already does that. Gitolite already have user > interaction mixed with git interaction. Do you say to me that gitolite > is broken and should not do user interaction over git-commands? Then why > does wild repos exists and why does gitolite error messages exists? > > We're already down that road, why not do it better? I think you misunderstood how gitolite works. Gitolite does not have *any* user interaction other than sending some extra messages back via STDERR if you're using a normal git client to do normal git operations (clone/fetch/ls-remote). Such messages are *no different* from something that an update or pre-receive hook might send back even on a normal (no gitolite) git server. The only time that gitolite might have any user *interaction* is when using "gitolite commands". These do not run git at all (neither on the client nor on the server), and in fact merely provide a convenient way to allow users to run a controlled set of specific *shell* commands. -- 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