Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
You might do better to ask this question on a more specialised forum, e.g. ikiwiki.info/forum. Unless that doesn't work for you, for some reason. –  Faheem Mitha Jun 10 at 21:46

1 Answer 1

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.