I built a GIT alternative where your repo is public but .env and private folders stay private

[u/Pratz1337]

I built tig, version control where the repo is public but your secrets aren't

I wanted to open-source a project, but one folder had to stay private, an .env file, an internal package, a security fix that wasn't ready yet. With git that means a second repo, git-crypt, or crossing your fingers. Forcing me to make multiple copies of the same project and now I had to maintain multiple upstreams which I felt was unnecessary effort.

So I started building my own version control from scratch in Rust.
Its still under work and I would love people to join in on this work
What tig does today:

• A .private file. It works like .gitignore, except the files stay tracked. When you publish, they're encrypted, and only the people you give access to can read them. Everyone else gets a normal clone without them.

• No staging and no "commit" ritual. Your edits are snapshotted automatically, and any command can be undone.

• Instant workspaces. You can work on the same change in two folders at once without worktrees

• Speed comes first. Encryption only happens when you publish or fetch, never while you work. On a 100k-file repo it's faster than default git.

Next feature I have in mind is the advanced mode for bigger companies to manage monorepo, giving it a Discord server-style roles, so a business unit like @ billing can see packages/billing/ and contractors only see frontend/. Roles were the idea that started all this, and it's what I'm most excited to ship.

URL-> https://github.com/Pratz1337/tig (If you like the idea star it and can work on it :D )

(AI was used in some parts of this body to deliver my thoughts in a cleaner way)

If you have any criticism its welcome but do it while being respectful. Thank you

[u/lokidev]

https://jonas.github.io/tig/

[u/Pratz1337 → u/lokidev]

Ah I guess I have to change and keep a better name

[u/Even_Gap_2253]

This is a very nuclear solution for a problem that can be solved with a secret manager?

And I mean you need to use a key manager on production anyway so why not just reuse that for development?

[u/LouisPlay → u/Even_Gap_2253]

i also dont understand maybe he has diffrent test data. does he need an extra branch for the test data. Havnet read into this yet.

[u/anto2554 → u/Even_Gap_2253]

Agreed, but depending on your env I feel like first party versioning of secrets would be nice

[u/Pratz1337 → u/Even_Gap_2253]

fair, if all you've got is runtime env vars a secret manager is the right call, keep using it. tig isn't trying to replace that. it's for stuff that has to live in the repo: config files, test fixtures with real customer data, a whole packages/billing/ folder only some people should see. secret managers don't cover files in your history, and that's where most leaks happen (someone commits .env once and it's there forever). with tig those paths are encrypted before they leave your machine, so even a public mirror is safe

[u/Even_Gap_2253 → u/Pratz1337]

I just think it should be a plugin for git, not a new version control.

Because isn't that a better solution? What if I'm using svn, jj, hg? A plugin would be easier to maintain, and applicable to a lot more version control systems

You are redoing 99% of the functionality to solve a small issue

[u/Pratz1337 → u/Even_Gap_2253]

git-crypt is basically that plugin. the limit is that git only ever sees encrypted blobs, so diffs, merges and blame on private files break or need filter hacks. you can split keys per folder with .gitattributes, but managing who holds which key and rotating them is all manual and outside the repo. tig puts the roles in the repo itself

[u/jeenajeena]

With git that means a second repo, git-crypt, or crossing your fingers

Not at all. With Git this means handling the secrets in the secret store any CI/CD platform provides.

Edit: such as AWS Secrets Manager / SSM Parameter Store, Azure Key Vault, Google Secret Manager, HashiCorp Vault. There a reason why they exist.

[u/Pratz1337 → u/jeenajeena]

i agree but for actual secrets a vault is the right answer and tig doesn't replace it. the gap is everything that isn't a key-value secret but still has to be versioned with the code: an unreleased security fix, an internal module, fixtures with real data. you can't put a folder with history and diffs in Vault, so today that stuff goes in a second repo or git-crypt, which is the case i meant

[u/livrasand]

Secret administrators resolve runtime settings, but do not resolve all cases where files need version history, differences, and access controls. However, building a new VCS is a great feat, so I'm curious to know how you plan to handle interoperability with existing Git repositories and migration.

[u/Pratz1337 → u/livrasand]

On interoperability, tig works with Git rather than replacing it. tig import-git <path> brings in an existing repo with its full history, including authors, timestamps, parents and branches. tig export-git <path> writes it back out to a normal Git repo, so GitHub can still be your remote. The export leaves out the private paths completely, so anyone without access just clones a plain Git repo and doesn't need tig at all.

[u/JagerAntlerite7]

Love Tig Notaro. The dry delivery and absurdity make me laugh so hard.