git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: RFC: a plugin architecture for git extensions?

From
Jon Seymour <jon.seymour@gmail.com>
Date
Apr 28, 2011, 09:42 UTC
Message-ID
<BANLkTin2Ts5C=Sp60w7xnkJ078MaNiroVw@mail.gmail.com>
In-Reply-To
<BANLkTi=b3bSt8VUvFJw2TiXZNXf0+wLj+Q@mail.gmail.com>
On Thursday, April 28, 2011, Pau Garcia i Quiles <pgquiles@elpauer.org> wrote:
Show 10 quoted lines
> On Thu, Apr 28, 2011 at 10:09 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
>
>> Ok, I have tried to explain why separating the concerns of package
>> management and plugin management is an appropriate thing to do, and
>> why one directory for each plugin is also a good thing to do. BTW: I
>> thought you actually suggested this concept yourself in your earlier
>> post.
>
> Please, re-read my mails. I *am* suggesting that plugins store data in
> different directories!

Good. Sorry I explained why an activation step is good for performance, particularly if you have a plugin architecture that uses multiple directories, one per plugin. I misinterpreted your confusion about why an activate step was necessary as an explicit rejection of my arguments that an activation step was a plus for performance and conflict detection in an environment in which each plugin is installed in it's own directory. Apologies.

Supposed you have 100 plugins. Suppose the user invoked git foobar where foobar is an installed plugin. How does git find the plugin to invoke? Why it has to scan 100 directories looking for a match.

If you use an activation step (just after installation) you get O(1) performance instead of O(n). Small gain for 2 plugins, I agree.

But then that isn't the only reason to use an activation step. As I said, an activation step alllows precise detection and prevention of conflicts that just isn't possible if you rely on first-in-PATH semantics.

It is true, you can delegate conflict detection to the package manager, but do you know what, that would be in Andreas"s words "Brilliant" as it would force package maintainers become git extension experts.

My proposal makes the git-core maintainerrthathe experts on git extension management and relieves plugin authors, package authors and package-manager authors of this responsibility.

I ask. is that not a very good thing?
Show 25 quoted lines
>
> - The "main command" (git-atomic, for instance) would be stored in
> GIT_PREFIX/lib/git-plugins (instead of GIT_PREFIX/lib/git-core, which
> is where git stores its commands). Git would have to learn to search
> in GIT_PREFIX/lib/git-plugins in addition to git-core, of course.
>
> - Porcelain for git-atomic would go to
> GIT_PREFIX/lib/git-plugins/git-atomic (or something like this)
>
> - The documentation would be stored in GIT_PREFIX/doc/git-atomic
>
> - Resources in GIT_PREFIX/share/git-atomic
>
> - etc
>
> I. e. each plugin stores its stuff in a separate directory, it's just
> that directory is not a *single* directory but *many* directories,
> each one inside the proper path under GIT_PREFIX, just like it is for
> anything you install on a Unix system
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
>
Previous: Pau Garcia i QuilesNext: Jon Seymour
Message 101 of 105 in “RFC: a plugin architecture for git extensions?”
  1. Jon SeymourApr 27, 2011
  2. Jonathan NiederApr 27, 2011
  3. Jon SeymourApr 27, 2011
  4. Junio C HamanoApr 27, 2011
  5. Jon SeymourApr 27, 2011
  6. Junio C HamanoApr 27, 2011
  7. Jon SeymourApr 27, 2011
  8. Jon SeymourApr 27, 2011
  9. Junio C HamanoApr 27, 2011
  10. Jon SeymourApr 27, 2011
  11. Jon SeymourApr 27, 2011
  12. Michael J GruberApr 27, 2011
  13. Jon SeymourApr 27, 2011
  14. Jon SeymourApr 27, 2011
  15. Motiejus JakštysApr 27, 2011
  16. Jon SeymourApr 27, 2011
  17. Motiejus JakštysApr 27, 2011
  18. Carlos Martín NietoApr 27, 2011
  19. Jon SeymourApr 27, 2011
  20. Fredrik GustafssonApr 27, 2011
  21. Jon SeymourApr 27, 2011
  22. Pau Garcia i QuilesApr 27, 2011
  23. Jon SeymourApr 27, 2011
  24. Ævar Arnfjörð BjarmasonApr 27, 2011
  25. Jon SeymourApr 27, 2011
  26. Enrico WeigeltMay 13, 2011
  27. Andreas EricssonApr 27, 2011
  28. Jon SeymourApr 27, 2011
  29. Felipe ContrerasApr 27, 2011
  30. Jon SeymourApr 27, 2011
  31. Andreas EricssonApr 27, 2011
  32. Jon SeymourApr 27, 2011
  33. Jon SeymourApr 27, 2011
  34. A Large Angry SCMApr 27, 2011
  35. Jon SeymourApr 28, 2011
  36. Jon SeymourApr 28, 2011
  37. Jon SeymourApr 28, 2011
  38. Jon SeymourApr 28, 2011
  39. david@lang.hmApr 28, 2011
  40. Jon SeymourApr 29, 2011
  41. Motiejus JakštysApr 27, 2011
  42. Motiejus JakštysApr 27, 2011
  43. Junio C HamanoApr 27, 2011
  44. Junio C HamanoApr 27, 2011
  45. Drew NorthupApr 27, 2011
  46. Joey HessApr 27, 2011
  47. Drew NorthupApr 27, 2011
  48. Junio C HamanoApr 27, 2011
  49. Jonathan NiederApr 27, 2011
  50. Jon SeymourApr 27, 2011
  51. Andreas EricssonApr 28, 2011
  52. Junio C HamanoApr 27, 2011
  53. Jonathan NiederApr 27, 2011
  54. Junio C HamanoApr 28, 2011
  55. Jon SeymourApr 28, 2011
  56. Jon SeymourApr 28, 2011
  57. david@lang.hmApr 28, 2011
  58. Jon SeymourApr 28, 2011
  59. Jon SeymourApr 28, 2011
  60. Jon SeymourApr 28, 2011
  61. Andreas EricssonApr 28, 2011
  62. Jon SeymourApr 28, 2011
  63. Jonathan NiederApr 28, 2011
  64. Jon SeymourApr 28, 2011
  65. David AguilarMay 5, 2011
  66. Junio C HamanoMay 5, 2011
  67. Jon SeymourMay 5, 2011
  68. Junio C HamanoMay 6, 2011
  69. Jon SeymourMay 6, 2011
  70. Jonathan NiederMay 6, 2011
  71. Jonathan NiederMay 6, 2011
  72. Jon SeymourMay 6, 2011
  73. Jonathan NiederMay 6, 2011
  74. Jon SeymourMay 6, 2011
  75. Jonathan NiederMay 6, 2011
  76. Jon SeymourMay 8, 2011
  77. Jonathan NiederMay 8, 2011
  78. Jon SeymourMay 8, 2011
  79. Jeff KingMay 6, 2011
  80. John SzakmeisterMay 7, 2011
  81. Jon SeymourMay 8, 2011
  82. Jeff KingMay 9, 2011
  83. Jon SeymourMay 9, 2011
  84. Jeff KingMay 9, 2011
  85. Jon SeymourMay 9, 2011
  86. Jeff KingMay 9, 2011
  87. Jon SeymourMay 9, 2011
  88. Jon SeymourMay 9, 2011
  89. Jeff KingMay 9, 2011
  90. Jon SeymourMay 9, 2011
  91. Jeff KingMay 9, 2011
  92. Jon SeymourMay 9, 2011
  93. Jon SeymourMay 8, 2011
  94. Miles BaderMay 9, 2011
  95. David AguilarMay 14, 2011
  96. Andreas EricssonApr 28, 2011
  97. Jon SeymourApr 28, 2011
  98. Pau Garcia i QuilesApr 28, 2011
  99. Jon SeymourApr 28, 2011
  100. Pau Garcia i QuilesApr 28, 2011
  101. Jon SeymourApr 28, 2011
  102. Jon SeymourApr 28, 2011
  103. Jon SeymourApr 28, 2011
  104. Motiejus JakštysApr 27, 2011
  105. Jon SeymourApr 27, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.