Re: [PATCHv3] Updated patch series for providing mechanism to list available repositories

[Greg Brockman <gdb@MIT.EDU>]

>>> Just sending a reminder about this patch series--I haven't seen any
>>> comments on it yet, so I assume it's gotten lost in the flurry of
>>> other list activity.
>>
>> It would probably help if you re-send the entire thing again.
>
> Wait wait, it’s only been about five days!
>
> I mean, you are free to re-send, but it is probably better to
> send a link to the gmane archive, like this:
>
>  http://thread.gmane.org/gmane.comp.version-control.git/151398
>
> so people can catch up with the earlier discussion.
Haha, ok.  Any rules of thumb for how long to wait until resending
everything is appropriate?

> In this case, I am nervous about the impact for existing installations
> with git-shell deployed.  If a person can smuggle in an unpleasant
> git-shell-commands directory somehow, the effect would not be good.
> Maybe there should be a way to disable this feature systemwide for the
> paranoid (or maybe not; I’m only vaguely worried).
You may have a point.  Although, if someone can drop in the
git-shell-commands directory, he or she can probably also edit one of
the git repo's hooks directories.  I'd be curious to hear others'
opinions on the matter.

> Patch 1 still uses execv(), which is not available on Windows.
It seems to me that the existing git-shell calls execv_git_cmd, which
uses execvp internally.  I know ~nothing about exec on Windows, but
presumably it doesn't have just one of execv or execvp.  If it does,
it would be easy enough to switch the execv to execvp, as the commands
that are being run are already guaranteed to have a slash.  Or am I
missing something silly again?

> Have you tried out these patches "in the wild"?  If so, that would be
> interesting to hear about.
Not yet.  My $project has deployed an earlier prototype of the patches
in our dev environment, but we haven't moved it to prod yet.  We'll
probably do that next week.

Greg