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

Re: Git Wiki improvements

From
Sean Estabrooks <seanlkml@sympatico.ca>
Date
Apr 14, 2008, 16:53 UTC
Message-ID
<BAYC1-PASMTP07541F260058BCB1E881EFAEE80@CEZ.ICE>
In-Reply-To
<87skxos93x.fsf@jeremyms.com>

On Mon, 14 Apr 2008 12:18:42 -0400 Jeremy Maitin-Shepard <jbms@cmu.edu> wrote:

Hi Jeremy,
Show 14 quoted lines
> I've thought about this possibility myself, but it seems that the clone,
> edit, commit, push cycle may not really be ideal for a wiki.  For one
> thing, it is hardly ever necessary or useful to have anything more than
> per-file commits.  Also, if there are a large number of simultaneous
> users trying to push to the repository, you could run into a problem
> whereby you can never successfully push because ever time you try, it is
> not a fast-forward, so you have to fetch then merge (we can assume the
> merge is just done automatically because e.g. only different files were
> modified) then try to push again, but before you have a chance to retry
> the push, the branch head may have changed again due to another push.
> 
> I suppose in practice this may not be a problem for the git wiki as it
> may not have so many contributors, but this would certainly be a problem
> for e.g. wikipedia.

Yeah, it should be okay on this scale, its the same as having multiple developers push into a common source repo. Ikiwiki itself is hosted in Git and handles its own wiki exactly this way. It can be updated via the web site or Git push. Running "git pull --rebase" before doing a push into the wiki isn't onerous.

Show 6 quoted lines
> More generally, though, although we may all dislike using webpage
> interfaces, actually having to keep the entire wiki updated locally
> doesn't seem terribly useful.  Really, you just want a way to edit a
> particular page in your text editor, have various commands available for
> e.g. previewing, and have commands available for showing the log
> information with a nicer interface than a web page.

The goal would be to make the help texts available in multiple ways. In a text editor, or converted into other formats for use with other tools. More importantly they should continue be easy to find with Google and editable via a browser for quick fixes by casual users. But as it stands, the wiki information is stuck on the web.

Git's documentation is already handled very close to this today. It's easy to clone the asciidoc source, read in a text editor, and turned into web or man pages. It seems attractive to do likewise for the wiki docs since the tools are all at hand.

Cheers, Sean

Previous: Jeremy Maitin-Shepard
Message 12 of 12 in “Re: Git Wiki improvements”
  1. Jakub NarebskiApr 14, 2008
  2. DillApr 14, 2008
  3. DillApr 14, 2008
  4. J.H.Apr 14, 2008
  5. DillApr 14, 2008
  6. DillApr 14, 2008
  7. Santi BéjarApr 14, 2008
  8. Johannes SchindelinApr 14, 2008
  9. Sean EstabrooksApr 14, 2008
  10. Johannes SchindelinApr 14, 2008
  11. Jeremy Maitin-ShepardApr 14, 2008
  12. Sean EstabrooksApr 14, 2008

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.