Why Git does not transfer
- Every application has its own project format, so a tool would have to understand each one individually rather than treating files as text.
- Showing a difference between two versions would require the application's own render engine, because the meaningful change is visual.
- The comparison one answer drew: an edit decision list is closer to Lightroom's history than to source code — an ordered record of changes applied to untouched originals.
What editors actually use
- Incremental project saves, which several applications will do automatically once enabled. One answer recommended raising the retained count well above the small default.
- Built-in restore-from-previous-version features, singled out as valuable for the specific case of an application corrupting its own project file.
- Asset management systems, which handle versioning, permissions and users across a facility's media. One contributor used one for version control and branching on project files in a post house.
Where the gap is real
The non-destructive argument has a limit the thread identified: it holds while everything stays as a live edit. Once something is pre-rendered and the rendered file becomes the thing you work with, the earlier state stops being reachable by undoing. One answer compared that to compiling part of a program into a library and then building against the library rather than the source — the history is still somewhere, but not in front of you any more.
Two caveats about this thread
- It is from 2014, and one asset management product it names was already obsolete when the answer was written. The categories are current; the products are not.
- It answers the project-file question rather than the footage question. Version control and backup are separate problems, and nothing here protects the source media.