14 lines
3.4 KiB
Plaintext
14 lines
3.4 KiB
Plaintext
Fossil is version-controlled code artifact management. Each fossil has an ID (treat it like a filename) and maintains complete edit history. Every change generates a diff and can be reverted.
|
|
|
|
The key architectural choice is between fuzzy_edit and fuzzy_replace. fuzzy_edit takes start_pattern and end_pattern and replaces everything between them (inclusive of the boundary lines). This is designed for structural changes where you're replacing entire functions, refactoring classes, or swapping out major blocks of logic. You're essentially saying "from this line to that line, replace it all with this new content." The patterns define boundaries and everything in between gets replaced.
|
|
|
|
fuzzy_replace works differently - it searches for old_str and swaps it with new_str, much like find-and-replace in a text editor. This is meant for surgical edits: renaming a variable throughout a function, changing a configuration value, fixing a specific line, or updating an import statement. When the pattern appears multiple times, use occurrence to specify which one (0 for first, -1 for last, or positive integers for nth occurrence). If you don't specify occurrence and multiple matches exist, the tool errors and tells you how many it found with their line numbers.
|
|
|
|
Both tools use Smith-Waterman fuzzy matching, which means they tolerate whitespace variations, minor formatting differences, and don't require character-perfect patterns. However "fuzzy" doesn't mean "vague" - patterns still need to be distinctive enough to match uniquely. If you search for a bare variable name like "count", it might match dozens of places. Include enough context to make it unambiguous: the full statement, the function signature, or surrounding code that makes the location clear. The matcher will handle if indentation changed or there's an extra space somewhere, but it won't guess which of five identical variable names you meant.
|
|
|
|
When edits fail, they fail atomically - nothing changes. Error messages include specifics: "pattern not found" means the fuzzy matcher couldn't align it with anything in the code (check if the code changed since you last saw it, or if your pattern has typos), "multiple matches" means your pattern is too generic (response includes line numbers of all matches so you can see what got caught), "invalid occurrence" means you asked for the 5th match but only 3 exist. Read the error details, they're designed to be actionable.
|
|
|
|
Version control works with integer indices. Version 0 is initial creation, positive indices count forward from start, negative indices count backward from current (so -1 is latest, -2 is previous, etc). Use get_version to review past states without changing anything - useful when you want to see what code looked like three edits ago without actually reverting. Use revert when you want to undo changes. You can revert multiple steps at once by specifying the steps parameter. Both return diffs showing what changed.
|
|
|
|
The system infers rendering from content and ID. A .tsx file with React imports gets rendered as a React component, .html gets rendered as HTML, .py shows as Python with syntax highlighting. The GUI provides copy/paste and lets users interact with rendered output. Files persist for the conversation duration with full history. Use fossils for code users will iterate on or actually use, not for throwaway examples or snippets under 20 lines that are just illustrative.
|