1

If I have a local ikiwiki on my laptop I need a "repository" directory (mywiki.git - a bare repository), a "scrdir" (myiki a git repository) and a place where the produced html files go ("destdir") to run it properly from a web browser locally.

However if I also want to work with a text editor and git on the command line I need to setup a third git repository say mywiki.local ("working clone"). Which puhes to mywiki.git which in turn triggers a post-update hook to push to the scrdir and rebuild the html pages, as illustrated in the following picture:

Workflow

With this approach, I need three almost identical directories on my laptop just to run one wiki, i.e. it occupies three times the disk space instead of just once.

What is the reason behind this?

Is there a safe way to circumvent this if you are just working on one machine, to reduce it to just two or even better one directory?

student
  • 17,875
  • 31
  • 103
  • 169
  • You might do better to ask this question on a more specialised forum, e.g. http://ikiwiki.info/forum/. Unless that doesn't work for you, for some reason. – Faheem Mitha Jun 10 '14 at 21:46
  • I second the suggestion. Asked recently about ikiwiki on stackoverflow and the question went under the radar. Go to ikiwiki, and ask at the Discussion subpage of a page you are refering to. Works really fast. – Martian Jun 30 '16 at 10:11

2 Answers2

4

It does seem excessive. It may be possible to deal with only one git repository. That all depends on the capabilities of the ikiwiki infrastructure (of which I know nothing about).

The Why

The reason you'll want the repository to be a bare repository is because a non-bare repository almost always will have a branch checked out. Other git repositories will are not allowed to deliver to a branch that is checked out on the destination repository (imagine working on the branch, a push happens to your machine, and files get changed from under your nose).

You may be able to work out of the srcdir instead of cloning the "repository" one. Although this may cause a resource contention if you can modify the files at the same time that a web-side edit can. Also, it could get messy with you pushing manually and having the ikiwiki.cgi pushes happening too. The ikiwiki may put in hooks you don't want running on a push. For this reason, I suppose they recommend you clone from the "repository".

A Feature of Git

When you clone a git repository from a local machine, git does significant optimizations. If you use the --local option (which is the default if you do git clone /path/to/repo), it uses hardlinking of the common history they share, thus saving disk space. Here is an excerpt from git help clone:

   --local, -l
       When the repository to clone from is on a local machine,
       this flag bypasses the normal "Git aware" transport
       mechanism and clones the repository by making a copy of
       HEAD and everything under objects and refs directories.
       The files under .git/objects/ directory are hardlinked to
       save space when possible.

The excess disk space is not in the .git/objects directory, but rather in the checkout itself. If that's still too excessive for you, then you may want to continue looking for another solution.

Conclusion

Unless you know a lot about the inner-workings of ikiwiki, I wouldn't attempt to circumvent their recommended way of setting it up. I would consider it unsafe. If you want a better answer than that, you may want to go to a better forum with more knowledge about ikiwiki.

The extra used disk space is less of an issue when you realize git performs hard-linking of the internal git object files.

TPS
  • 2,483
  • 5
  • 27
  • 45
mikebob
  • 186
  • 4
2

I have successfully used ikiwiki with 0+ repositories.

0..2 are single-user, so I have not run into conflicts (yet). 0..1 were just an experiment with ikiwiki.

Here is what I tried:

  • 0 repositories - compiling manually,
  • 1 repository (working directory == srcdir) without upstream - compiling manually,
  • 2 repositories (working directory == srcdir + upstream)
  • 3+ repositories (the above 2 on server + remote on a NB)

With 3+ we are going multiuser, so I expect it is going to be more interesting.

I was seeking an answer to same question as yours, so here is the answer:

If you are directly editing ikiwiki srcdir you will run into a conflict if the same file is edited by web-ui (or pushed to bare repo by other users).

If you commit in srcdir, conflict will be handled by web-ui.

But any uncommitted changes to the file will be lost.

If you are not using web editing feature, and there are no other users committing to the repo, you are fine with 2 repos. And even 1 might work. Or 1 with remote repository.

Also I guess it would be easy to write a plugin to stash any changes before srcdir is updated/reset.

Martian
  • 206
  • 1
  • 4