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?
-
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