On Sun, Jul 29, 2012 at 8:35 PM, Fredrik Gustafsson <iv...@iveqy.com> 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

Such messages are *no different* from something that an update or
pre-receive hook might send back even on a normal (no gitolite) git

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*
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to