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

Re: moving to a git-backed wiki

From
Jeff King <peff@peff.net>
Date
Feb 3, 2011, 17:45 UTC
Message-ID
<20110203174518.GA14871@sigill.intra.peff.net>
In-Reply-To
<4D4A11D7.4040103@eaglescrag.net>
On Wed, Feb 02, 2011 at 06:24:23PM -0800, J.H. wrote:
Show 14 quoted lines
> On 02/02/2011 01:55 AM, Vincent Hanquez wrote:
> >  On 01/02/11 22:48, J.H. wrote:
> >> The wiki will almost universally have a "central site" no matter what
> >> the backend.  Personally I see little advantage to having a git backed
> >> wiki myself.
> > with git based wiki, you can clone the whole wiki on your local machine,
> > and read/edit/commit on it locally using standard editor tool (i.e.
> > $EDITOR). and the history/revision/diff is completely built-in.
> 
> That would be fine for things like source code or documentation, but you
> end up with a single person who would need to merge / push things to a
> central location, a-la git.wiki.kernel.org.  You are now taking
> something, that is already editable by anyone, and making it only
> editable by a single person.

I don't think it makes sense to use the same workflow for the wiki as git.git itself uses. The point of having a wiki is to keep the barrier to editing extremely low; the point of source code control is to keep the quality of contributions high.

But that doesn't mean they can't be accessed by the same tool.

Forget about a git-backed wiki for a moment, and imagine a regular old Mediawiki. What are the operations you can perform? You can look at the current or any past version of a page, you can do diffs between versions of pages, and you can create a new version of a page. All through some CGI forms.

So what stops us from replacing the CGI interface with a git one (or adding it alongside)? Given the ability to retrieve current and past versions of all pages, I could surely build a git repository of the whole wiki (and update it incrementally as new edits were made). And pushing a set of commits is just a sequential series of page edits, no?

And I think that would be enough for the purposes of this discussion. Most of us don't really care if git is the ultimate storage mechanism. I could even build the git interface as a purely client thing on top of the CGI interface; the problem is that scraping the wiki pages for new versions over the net would be horribly inefficient.

But the point is that accessing the wiki via git is not about changing the wiki workflow. It's about providing a richer set of tools for doing those page views, diffs, and edits.

Getting back to git as the actual backend:
> You also have a scalability problem.  Git is *VERY* memory and i/o
> intensive.  While you basically have a cache of data that is static (the
> basic pages you are viewing) things like the history, edits, etc can be
> quite expensive to generate.

Sure. But is that any worse than running gitweb, which you already do? Or a site like GitHub, which basically is just running git constantly on a bunch of repos? Or how much worse is it than running regular wiki software? I mean, Foswiki is backed by RCS, for god's sake. Surely git is more efficient than that. ;)

If it sounds like I'm handwaving away scalability problems, I am. I'd be curious to see some performance numbers for gollum or ikiwiki versus more traditional wiki formats.

Show 5 quoted lines
> Think about a site, we'll use git.wiki.kernel.org, where it's not
> running on a single machine, but a cluster of machines (how many web
> infrastructures, including git.wiki.kernel.org run) and now you have a
> problem of an edit happens and commits on node3, a different conflicting
> edit happens on node9 and when those try to merge - you get conflicts.

Don't you have the same problem with a regular wiki? Or with stock git repos, for that matter? You need database consistency.

-Peff
Previous: J.H.Next: Sverre Rabbelier
Message 21 of 126 in “What's cooking in git.git (Jan 2011, #06; Sun, 30)”
  1. Junio C HamanoJan 31, 2011
  2. Sverre RabbelierJan 31, 2011
  3. Sverre RabbelierFeb 8, 2011
  4. Junio C HamanoFeb 8, 2011
  5. Planning for 1.7.5 and 1.8.0Junio C Hamano, Jan 31, 2011
  6. [1.8.0] default "git merge" without argument to "git merge @{u}"Junio C Hamano, Jan 31, 2011
  7. Jeff KingJan 31, 2011
  8. Junio C HamanoJan 31, 2011
  9. Felipe ContrerasJan 31, 2011
  10. [1.8.0] (v2) default "git merge" without argument to "git merge @{u}"Junio C Hamano, Jan 31, 2011
  11. Jeff KingJan 31, 2011
  12. Thomas AdamFeb 1, 2011
  13. Scott ChaconFeb 1, 2011
  14. moving to a git-backed wikiJeff King, Feb 1, 2011
  15. Jay SoffianFeb 1, 2011
  16. J.H.Feb 1, 2011
  17. Vincent HanquezFeb 2, 2011
  18. Felipe ContrerasFeb 2, 2011
  19. Jakub NarebskiFeb 2, 2011
  20. J.H.Feb 3, 2011
  21. Jeff KingFeb 3, 2011
  22. Sverre RabbelierFeb 3, 2011
  23. Jeff KingFeb 4, 2011
  24. Felipe ContrerasFeb 3, 2011
  25. Jeff KingFeb 4, 2011
  26. Felipe ContrerasFeb 4, 2011
  27. Joey HessFeb 4, 2011
  28. david@lang.hmFeb 5, 2011
  29. Thomas HochsteinFeb 4, 2011
  30. Add support for merging from upstream by default.Jared Hance, Feb 4, 2011
  31. [1.8.0] Unify "pathspec" semanticsJunio C Hamano, Jan 31, 2011
  32. Nguyen Thai Ngoc DuyFeb 1, 2011
  33. [1.8.0] reorganize the mess that the source tree has becomeNicolas Pitre, Jan 31, 2011
  34. Junio C HamanoJan 31, 2011
  35. Matthieu MoyJan 31, 2011
  36. Nicolas PitreJan 31, 2011
  37. Nicolas PitreJan 31, 2011
  38. Jeff KingJan 31, 2011
  39. Nicolas PitreJan 31, 2011
  40. Junio C HamanoJan 31, 2011
  41. João P. SampaioJan 31, 2011
  42. Nicolas PitreJan 31, 2011
  43. Jeff KingJan 31, 2011
  44. Nicolas PitreFeb 1, 2011
  45. Jeff KingFeb 1, 2011
  46. Nicolas PitreFeb 1, 2011
  47. Thomas RastFeb 1, 2011
  48. Jonathan NiederFeb 1, 2011
  49. Jonathan NiederFeb 1, 2011
  50. Nicolas PitreFeb 1, 2011
  51. Nguyen Thai Ngoc DuyFeb 1, 2011
  52. Junio C HamanoFeb 1, 2011
  53. Erik Faye-LundFeb 1, 2011
  54. Jeff KingFeb 1, 2011
  55. Sverre RabbelierFeb 1, 2011
  56. Jeff KingFeb 1, 2011
  57. Jay SoffianFeb 1, 2011
  58. Andreas EricssonFeb 1, 2011
  59. Jakub NarebskiJan 31, 2011
  60. Nicolas PitreJan 31, 2011
  61. Alex BudovskiFeb 1, 2011
  62. Nicolas PitreFeb 1, 2011
  63. Jakub NarebskiFeb 1, 2011
  64. Junio C HamanoFeb 1, 2011
  65. Sam VilainFeb 2, 2011
  66. [1.8.0] split largest remaining scripts, gitk and gitwebJakub Narebski, Feb 1, 2011
  67. Junio C HamanoFeb 1, 2011
  68. Jakub NarebskiFeb 1, 2011
  69. Martin von ZweigbergkFeb 5, 2011
  70. [1.8.0] make two-argument fetch update remote branchesThomas Rast, Jan 31, 2011
  71. Matthieu MoyJan 31, 2011
  72. Junio C HamanoJan 31, 2011
  73. Eugene SajineJan 31, 2011
  74. Junio C HamanoJan 31, 2011
  75. Eugene SajineJan 31, 2011
  76. Junio C HamanoFeb 1, 2011
  77. Jeff KingJan 31, 2011
  78. Jay SoffianFeb 1, 2011
  79. Nguyen Thai Ngoc DuyFeb 1, 2011
  80. Junio C HamanoFeb 1, 2011
  81. A Large Angry SCMFeb 1, 2011
  82. Thomas RastFeb 1, 2011
  83. A Large Angry SCMFeb 1, 2011
  84. [1.8.0] forbid full fetchspecs in git-pullThomas Rast, Jan 31, 2011
  85. Junio C HamanoJan 31, 2011
  86. Dmitry PotapovJan 31, 2011
  87. Thomas RastFeb 1, 2011
  88. Dmitry PotapovFeb 1, 2011
  89. Nguyen Thai Ngoc DuyFeb 1, 2011
  90. Nicolas PitreFeb 1, 2011
  91. [1.8.0] Tag namespacesMarc Branchaud, Feb 1, 2011
  92. Nguyen Thai Ngoc DuyFeb 1, 2011
  93. [1.8.0] Remove deprecated commandsRené Scharfe, Feb 1, 2011
  94. Junio C HamanoFeb 1, 2011
  95. Jonathan NiederFeb 2, 2011
  96. René ScharfeFeb 10, 2011
  97. Jonathan NiederFeb 10, 2011
  98. Junio C HamanoFeb 10, 2011
  99. René ScharfeFeb 12, 2011
  100. Jonathan NiederFeb 12, 2011
  101. Junio C HamanoFeb 13, 2011
  102. [1.8.0] Handle submodule config options consistently in diff plumbingJens Lehmann, Feb 1, 2011
  103. [1.8.0] Tracking empty directoriesJakub Narebski, Feb 2, 2011
  104. Jay SoffianFeb 2, 2011
  105. David AguilarFeb 2, 2011
  106. Jakub NarebskiFeb 2, 2011
  107. Wesley J. LandakerFeb 3, 2011
  108. Jonathan NiederFeb 3, 2011
  109. Matthieu MoyFeb 3, 2011
  110. Pete HarlanFeb 5, 2011
  111. Thomas KochFeb 5, 2011
  112. Sverre RabbelierFeb 5, 2011
  113. Jared HanceFeb 5, 2011
  114. Junio C HamanoFeb 6, 2011
  115. Sverre RabbelierFeb 6, 2011
  116. Nguyen Thai Ngoc DuyFeb 6, 2011
  117. [1.8.0] git-stash invocation changesThomas Rast, Feb 2, 2011
  118. Shawn PearceFeb 2, 2011
  119. Matthieu MoyFeb 2, 2011
  120. Thomas RastFeb 2, 2011
  121. Pat NotzFeb 9, 2011
  122. [1.8.0] Don't copy "submodule.<name>.update" to .git/config on submodule initJens Lehmann, Feb 23, 2011
  123. Junio C HamanoFeb 23, 2011
  124. Jens LehmannFeb 23, 2011
  125. Junio C HamanoFeb 24, 2011
  126. Jens LehmannFeb 24, 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.