Automating Git commits for external Gollum wiki edits

The challenge with external Gollum wiki edits

Gollum is a powerful Git-backed wiki system that automatically handles version control when changes are made through its web interface. However, many teams prefer the flexibility of editing wiki content through external means—whether using text editors like Vim, integrated development environments, or automated content generation scripts. This creates a synchronisation challenge: changes made outside Gollum's interface aren't automatically committed to the Git repository.

Without proper handling, this leads to several problems:

• External edits remain untracked until manually committed
• Web interface users may encounter merge conflicts
• Version history becomes fragmented and disorganised
• Changes may be lost if not properly committed

This article demonstrates how to create an automation solution that monitors and commits external changes to Gollum wikis, maintaining a consistent version history regardless of how edits are made.

Prerequisites

To implement the solutions described in this article, you'll need:

• A Gollum wiki setup with Git as the backend
• Basic knowledge of shell scripting
• Access to set up cron jobs on your system
• Understanding of Git fundamentals
• Administrator access to the wiki server

Understanding how Gollum interacts with Git

Before diving into the solution, it's important to understand how Gollum manages Git operations. Gollum is essentially a web frontend for Git repositories structured as wikis. When you make changes through the web interface, Gollum:

1. Creates a workspace with your changes
2. Stages the modifications using git add
3. Commits the changes with attribution information
4. Optionally pushes to a remote repository if configured

The key insight is that Gollum doesn't constantly monitor the filesystem for changes—it only manages Git operations for changes made through its interface. This means external edits remain in an uncommitted state until someone manually runs Git commands or makes another edit through the web interface (which might create conflicts).

Basic solution: shell script for single wiki

The simplest solution is a shell script that automates Git operations for a single wiki repository. Here's the basic implementation:

#!/bin/sh

# Navigate to wiki directory
cd /path/to/your/wiki || exit

# Stage all changes
git add --all .

# Only commit if there are changes to commit
if git diff --staged --quiet; then
    echo "No changes to commit"
else
    git commit -m "Automated commit of external edits at $(date)"
fi

This script performs three essential operations:

1. Changes to the wiki directory (with error handling if the directory doesn't exist)
2. Stages all modifications, additions, and deletions
3. Commits changes only if staged changes exist

Understanding the commit message

The commit message uses the date command to include a timestamp, making it easy to identify when the automated process ran. You can customise this message to include more context:

git commit -m "Automated commit of external edits at $(date) on $(hostname)"

This enhanced version adds the hostname, which is particularly useful in multi-server environments.

Advanced solution: managing multiple wikis

For organisations with several Gollum wikis, a more sophisticated approach uses an array to process multiple repositories in sequence:

#!/bin/bash

# Array of wiki paths to check
declare -a WIKIS=(
    "/home/user/wikis/project-docs"
    "/home/user/wikis/team-wiki"
    "/home/user/wikis/knowledge-base"
)

# Log file location
LOG_FILE="/var/log/wiki-commit-script.log"

# Current timestamp
TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S")

echo "=== Wiki commit job started at $TIMESTAMP ===" >> "$LOG_FILE"

# Process each wiki
for wiki in "${WIKIS[@]}"
do
    if [ ! -d "$wiki" ]; then
        echo "Error: Wiki directory not found: $wiki" >> "$LOG_FILE"
        continue
    fi

    echo "Processing wiki: $wiki" >> "$LOG_FILE"
    cd "$wiki" || continue

    # Stage all changes
    git add --all .

    # Only commit if there are changes to commit
    if git diff --staged --quiet; then
        echo "No changes to commit for $wiki" >> "$LOG_FILE"
    else
        git commit -m "Automated commit of external edits at $TIMESTAMP"
        echo "Changes committed for $wiki" >> "$LOG_FILE"
    fi
done

echo "=== Wiki commit job completed at $(date "+%Y-%m-%d %H:%M:%S") ===" >> "$LOG_FILE"

This enhanced script includes several improvements:

1. Defines wiki locations in a single configurable array
2. Implements logging to track execution history
3. Adds error handling for missing directories
4. Uses consistent timestamps across commit messages
5. Reports completion status for each wiki

Setting up automated execution with cron

For continuous monitoring, configuring the script to run automatically via cron is essential. Here's how to set it up:

1. Save your script to a permanent location, e.g., /home/user/scripts/wiki-commit.sh
2. Make it executable:

   chmod +x /home/user/scripts/wiki-commit.sh
   

3. Edit your crontab:

   crontab -e
   

4. Add an entry to run the script at your desired frequency:

   # Run every 5 minutes
   */5 * * * * /home/user/scripts/wiki-commit.sh
   
   # Alternatively, run hourly
   0 * * * * /home/user/scripts/wiki-commit.sh
   

Managing script execution permissions

If your wikis are owned by a different user (e.g., a web service account), you may need to run the script as that user:

# In crontab
*/10 * * * * sudo -u www-data /home/user/scripts/wiki-commit.sh

Alternatively, you can configure the cron job in the service user's crontab:

sudo -u www-data crontab -e

Advanced techniques and customisations

Intelligent commit messages

Instead of generic timestamps, you can create more descriptive commit messages by analysing what changed:

#!/bin/bash

cd /path/to/wiki || exit

# Get list of changed files
CHANGED_FILES=$(git diff --name-only)

if [ -z "$CHANGED_FILES" ]; then
    echo "No changes detected"
    exit 0
fi

# Count changed files
NUM_CHANGED=$(echo "$CHANGED_FILES" | wc -l)

# Generate commit message based on changes
if [ "$NUM_CHANGED" -eq 1 ]; then
    # Single file changed - use its name in commit message
    FILE_NAME=$(echo "$CHANGED_FILES")
    git add "$FILE_NAME"
    git commit -m "Updated $FILE_NAME via external edit"
else
    # Multiple files changed
    git add --all .
    git commit -m "Updated $NUM_CHANGED files via external edits"
fi

Adding remote synchronisation

If your Gollum instance works with a remote repository, you can add push operations:

#!/bin/bash

cd /path/to/wiki || exit
git add --all .

if ! git diff --staged --quiet; then
    git commit -m "Automated commit of external edits at $(date)"

    # Push to remote repository
    if ! git push origin main; then
        echo "Error: Failed to push changes to remote repository" >&2
    fi
fi

Conclusion

Automating Git commits for external Gollum wiki edits bridges the gap between web-based and external editing workflows. The solution ensures consistent version history regardless of how content is modified.

As you implement this approach, consider these best practices:

• Tune the commit frequency to match your team's editing patterns
• Use descriptive commit messages to maintain a meaningful history
• Implement proper logging for troubleshooting
• Consider workflow notifications to alert editors when automatic commits occur

These automation techniques can be extended to other Git-backed systems beyond Gollum, making them valuable tools in any documentation workflow where multiple editing methods coexist.

For further exploration, consider implementing pre-commit hooks to validate content, or integrating with CI/CD pipelines to automate content deployment after commits.