Re: VCS comparison table

[Charles Duffy <cduffy@spamcop.net>]

Johannes Schindelin wrote:
>> I presume that for this reason you will also never, _never_ use a 
>> non-mainline branch of git -- even if its actual code only touches UI 
>> enhancements or something similarly non-core
>>     
>
> NO! The point was that I will not gladly run anything which could change 
> the core. If I know it touches only the UI, there is no problem.
>   

If you're willing to look at the source of a branch to know that it 
touches only the UI, why would you not be willing to look at the source 
of a plugin to do the same thing?

> If I get a shell script using git-core programs to do its job, I 
> _know_ that my repository will not be fscked afterwards.
>
> And _that_ was the whole point of my email.
>   

It's a silly point. If you're willing to look at what your shell script 
does and validate that it doesn't do LD_PRELOAD tricks or swap out git 
core pieces, why wouldn't you be willing to accept a plugin after a 
similar level of review, rather than stating outright that you would 
*never* use them?

>> The claim that an extensibility mechanism should be rejected wholesale 
>> on account of being excessively powerful, on the other hand, is just 
>> silly.
>>     
>
> Oh, but NO! An extensibility mechanism which allows for a fragile system 
> _is_ silly. Not my rejection of it.
>   

Shell scripts allow for a fragile system because they could include C 
code snippets which they then compile and LD_PRELOAD. Sure, they "allow 
for" a fragile system -- but the author has to go out of their way to 
make it so. Similarly, folks writing bzr plugins need to take explicit 
actions to monkeypatch existing code (as opposed to adding a new 
transport/storage format/command/etc but leaving the old ones alone).

If you trust the author of your shell script not to build their own 
LD_PRELOAD at runtime, why don't you trust the author of your bzr plugin 
not to monkeypatch in replacements to core code if they say they aren't?