On Wednesday, April 27, 2011, Andreas Ericsson wrote: > On 04/27/2011 05:36 AM, Jon Seymour wrote: >> Has anyone ever given consideration to git supporting a plugin >> architecture for git extensions? >> >> The idea would be to provide a consistent way to install, and address >> extensions to the core git functionality in a manner that does not >> require the extension to actually be integrated into the git core. >> > > Horrible idea. There are already as many package managers as there > are packages without us throwing another one into the mix. > I agree that there are too many package managers. But do you know what? There isn't a single package manager that reliably works across platform. apt-get? great. Except you need something else for Mac, cywgin, or, um Fedora. Brew? Fine then you only need to worry about Linux and cygwin. Cygwin? ... The platform for my extension is git. Not Mac. Not Debian. Not Fedora. Not cygwin. git. The lowest common denominator across these environments is, um, git. I challenge the sceptIcs to specify a one line command script that works across all possible environment that is more succinct than: git pm install gitwork It shouldn't be too hard. A tar command here, an enviroment variable edit there. Perhaps a curl command or a browser download. You have 4 words. Knock yourself out. >> For example, I have recently proposed a new command 'git work' >> https://github.com/jonseymour/git/blob/master/README.md which I think >> is a really useful extension to git. >> >> I haven't had much feedback for the concept. I am not sure if it is >> because people are too busy, just don't grok it, or grok it and don't >> think it is useful. >> > > I had a look at the manpage. It seems to do more or less exactly what > the same command would do without the word "work" thrown in, so either > it's quite useless or you've failed to describe its usefulness in the > manpage. > It is far from useless, so I have clearly failed with the explanation. I will post later,perhaps with some diagrams. > "git atomic" seems nice though. > Thank you! >> So, perhaps it won't be included in git. That's fine, I can build my >> own fork of git which includes the proposed extension [ indeed, this >> is how I originally developed it]. That's fine for >> me, but it isn't the most practical way to distribute it to others >> since I'll have to produce distribution packages for a variety of >> different distribution formats or fallback to tars and zips. >> > > What you can do is let your Makefile (or some other install-script) > take the destination path for "make install" (or equivalent) from > the output of "git --exec-path". > > That way, you can ship "git extadd" or whatever you want to call it > as a simple installer that installs executable and man-page in their > proper locations. If the commands you install require configuration > by default I'd say they're broken to begin with, but even that can > be remedied by running "git config --add key value" from the installer. > > So in a way, git is already its own pkg-config binary and anyone > clever enough to write useful scripts that enhances git will almost > certainly see that and use it from their favourite language quite > without having to learn some new magic format for package management. > Those 3 paragraphs were substantially longer than 4 words. Again, there is a tar ball, let me know how I can install it across alll environments that got runs on. Make sure the man pages work. jon. > -- > Andreas Ericsson          andreas.ericsson@xxxxxx > OP5 AB               www.op5.se > Tel: +46 8-230225         ÂFax: +46 8-230231 > > Considering the successes of the wars on alcohol, poverty, drugs and > terror, I think we should give some serious thought to declaring war > on peace. > -- 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