gitevolved docs

How it works

Why recording operations instead of text lines removes the conflicts that never needed to happen.

An edit is an operation, not a diff

Plain git stores changes as text: which lines were added or removed. When it merges, it works line-by-line, so two edits near each other look like a collision even when they're unrelated.

gitevolved records the operation you performed — AddFunction, RenameSymbol, RewriteRegion, and so on — in an append-only log. Your files are a projection of that log: gitevolved replays the operations to produce the current tree on demand.

Why that removes false conflicts

Because edits are structured operations, gitevolved can tell that "add a function at the bottom" and "rename a symbol at the top" are independent — two different operations on two different parts of the file. It combines them and both land. No conflict markers, no manual resolve step.

What still needs a human: when two operations genuinely change the same code, that's a real conflict and gitevolved asks you to decide. It only removes the conflicts that line-based diffing invented.

It's still git

gitevolved shells out to your real, installed git via the standard remote-helper mechanism — it never forks or links git internals. dosource:// is just a git remote. git clone, git fetch, git push work like any remote, and git push origin to GitHub is completely unaffected. You can use both remotes side by side.

Local first, team optional

The engine — recording operations, projecting files, detecting conflicts, exporting to a normal git commit — runs entirely on your laptop, with no account. When a whole team (and their agents) work on one codebase, a hosted cloud keeps everyone in sync; from your side it's just git push dosource://cloud/<repo> and concurrent pushes stay consistent. You never have to think about how that coordination happens — you push, it lands.