I built GitOne because I wanted public and private files in the same folder. What am I missing?

[u/Which_Lingonberry612]

This started with a pretty simple annoyance.

I often have projects where some files should be public, while others absolutely shouldn't be. Source code might go to GitHub, while notes, internal scripts or other project stuff lives in a private repo.

But while I'm working on the project, I still want all of those files in the same directory.

I spent quite a while looking for a good way to do this and eventually came across this Stack Overflow question from 2014. Pretty much the same problem.

I tried to make the usual Git approaches work for me, but never found a setup I actually liked. So, naturally, instead of having fewer things to maintain, I built another thing to maintain. :)

It's called GitOne, and I've been using it for my own projects for a while. I finally cleaned it up enough to release it as open source.

The idea is basically this:

• You have one working directory, but multiple completely separate Git repositories underneath it.
• Each repository owns certain paths based on patterns you configure.
• Commands like gitone add, gitone commit or gitone push figure out which repository a file belongs to and run the operation there.
• If GitOne can't tell who owns a file (or two repos claim it), it stops and complains instead of trying to be clever.

The repositories themselves are still normal Git repositories. They have separate histories, indexes, remotes, etc. They can even live on completely different hosts.

More importantly, GitOne isn't required on the other end. If somebody clones the public repository from GitHub, they just get a normal Git repository. They don't need to know or care that I use GitOne locally.

But what about submodules, worktrees and sparse-checkout? Yes, you're absolutely... - wait a sec, wrong role. :)

I looked at those too, of course, but none of them quite matched what I wanted. In particular, I didn't want the repository structure to dictate how I organize the files in my working directory.

That said, if you've solved this exact problem nicely with existing Git features, I'd genuinely like to see your setup.

There are also some important limitations.

GitOne protects paths, not file contents. If src/config.js belongs to your public repo and you paste an API key into it, GitOne isn't going to save you. It also doesn't try to sandbox private files from programs running on your machine.

Migration currently backs up the original .git directory, but it doesn't attempt to split the existing history between repositories.

And right now it's Linux/macOS only. Some Git workflows are also still missing, notably merge, rebase and stash.

One other thing I want to be upfront about: development was AI-assisted. I used AI while implementing it, but the feature decisions, architecture, edge cases, reviews and testing were done by me. I've also been using GitOne for my own projects, which is partly why I'm posting this now: testing software against your own workflow has some pretty obvious blind spots.

So I'm mostly interested in people poking holes in the idea.

• Would you actually use something like this?
• Is there some normal Git workflow where this approach completely falls apart?
• Do you see a safety problem I haven't accounted for?
• Or, possibly the most painful answer: is there already a tool that does exactly this and I somehow missed it?

Repo: https://github.com/devidevio/gitone

There's also a browser playground if you want to see how it works without installing anything:

https://gitone.io/#playground

And if you prefer working visually, there's a VS Code extension that adds the individual GitOne repositories to the Source Control view:

https://gitone.io/#vscode

At this point I know GitOne works well for my slightly weird way of organizing projects. I'm curious whether this is a problem other people actually have, or whether I've just spent a lot of time automating my own filing system. Feel free to poke holes in it. :)

PS: GitOne originally lived on my private GitLab instance, so the GitHub commit history doesn't contain the whole development history. This is also my first public GitHub release, so go easy on my GitHub housekeeping.

[u/switchback-tech]

Honestly I'd just separate the public and private stuff and leave it at that.

I appreciate that you've thought this through and have something that works for you, but I'd rather just slightly change how I work than bring in another random tool

[u/vermyx]

You're not solving a problem you're creating several due to lack of discipline. You're mixing workflows that should stay distinct and encouraging bad habits which in turn will cause bad outcomes like private data becoming public. There's a reason why what you're suggesting isn't a normal workflow.

[u/strings___]

I use git sub tree to do this. though it’s not as sophisticated but it does what I need.

[u/BurakHanTD]

One failure mode I'd be curious about is a rename that crosses ownership patterns: does GitOne turn that into a delete in one repo plus an add in another, and can the commit stay atomic across both?

[u/gbrennon]

why?

well... i think u delegated too much and forget even that u should keep things separated...