How I Submitted a PR to an 18k-star Project

Recently, a client wanted an internal documentation knowledge base that could also be deployed privately to fit their requirements. After some research, I picked BookStack, an open-source project built with Laravel/PHP that has 18k+ stars on GitHub.

After pulling the code, I started it locally with . The UI came up, but the container logs showed a fatal error:

This comes from Git's security checks introduced in Git 2.35.2+. If Git decides the ownership/permissions of a repo directory look suspicious, it refuses to run Git operations in that directory.

In BookStack's dev container, Git is part of the normal runtime flow. Once the repository is marked “unsafe,” the Git commands fail and the container may exit via the entrypoint script, which can look like it “crashed out of nowhere.”

In this setup, the code is mounted into the container at via a volume. The user running inside the container doesn't match the UID/GID of the files on the host, which triggers Git's “dubious ownership” protection.

Here is the relevant config ():

In my environment (Windows + WSL2), the host directory UID defaults to , but the PHP (Apache) user inside the container had a different UID. Git therefore considered ownership unreliable and threw the fatal error.

You can hit a similar issue on macOS: the default UID is often , and the container user usually doesn't match. In cross-platform dev setups, mismatched volume ownership is common.

The fix is straightforward: since is the project directory and we know it's a trusted mount, we can mark it as a safe Git directory.

I chose to fix it in the Dockerfile so it applies consistently:

I submitted this change as a PR, and the maintainer merged it quickly.

The takeaway: submitting a PR isn't hard. Sometimes it's just about noticing one small thing and going one step further. If you stay curious, you'll eventually find the perfect fix a project actually needs.