On Thu, Apr 28, 2011 at 7:11 PM, Andreas Ericsson <ae@xxxxxx> wrote: > On 04/28/2011 04:15 AM, Jon Seymour wrote: >> >> * suppose that git-core defined a git install _interface contract_ but >> did not define an implementation. >> > > Please. I'm already on my way to a seriously boring sales meeting without > having developers throw garbage terms on me. You've done a lot of that in > this thread and I for one am confused by them as to what you want to > achieve and how you want to achieve it. > I am confused. Is "interface contract" a "garbage term" for you? As I understand the term, it is a good way to enable strong separation of concerns and information hiding and these techniques are both valuable tools in the battle against complexity, a battle that I understand from other posts this in thread you are vitally engaged in. My apologies, if terms such as "separation of concerns" and "information hiding" are viscerally offensive to you. I must learn to deploy phrases such as "horrid" and "utterly horrid" with more panache and aplomb. >> Then, a distribution could install its own implementation of the >> git-install plugin into git installations it manages. >> >> Then a command like: >> >> Â Â Âgit install gitwork >> >> would trivially work across all distributions precisely because the >> distribution has provided the implementation of the git install >> interface contract that git-core has helpfully mandated. >> > > And so we force package maintainers to become git extension developers. > Brilliant. They'll love you for it. This exactly the wrong way around, but I can understand your mistake since I used this phrase: - distributions would know how to run git plugin activate and properly handle non-zero return codes from same when precision dictates that I should have used the more wordy, but more accurate: - distributions would know how to invoke plugin installation scripts provided by the plugin author, and these plugin installation scripts would, by virtue of being intimately aware of the public interfaces (oops, there is that word again) of git, know how to invoke the git plugin command in order to activate their own plugin. I have explained in my most recent reply to Pau that in the absence of a plugin management script provided by the git core, any hope of plugin conflict management has to be delegated to other parties such as the package manager author, the package author or the plugin author or, alas, to the poor user. I fail to see why management of plugin conflicts is better handled by N authors and M users, rather than a single author of the git-plugin script [ except for the minor detail that the only potential author of such a script seems to spend all his time writing e-mails instead of cutting code ]. jon. -- 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