Project description

ComIntern: Commit Internalizer
==============================

## What is this?
ComIntern will be a software to visualize how software projects are developed, and optionally save said visualizations to a video file.

Similar software projects are:
- [Gource](https://gource.io/)
- [code_swarm](https://github.com/rictic/code_swarm)

Example visualizations (similar to what this project targets to recreate):
- [for Gource](https://youtu.be/zRjTyRly5WA?si=346EWdAz-iGFa7uH)
- [for code_swarm](https://youtu.be/cuWoiAjWlbg?si=6LnjdFEIhF2MF3W9)

## Technology Stack

F#, Raylib

## Commit graph processing
### Find a way to serialize commit graph
Currently, I believe the best way would be to do hybrid approach. For unordered commits (that are done in parallel branches and have no particular ordering between them), sort by date.

For ordered commits, sort according to their natural order in graph, and then by date.

What date to consider? I prefer to use the author date if it's in range of our current scope (e.g. the author date fits between the neighbor dates), otherwise the committer date.

## How the video should look like?
The other commit visualizers often miss the file size issues. I want the commit authors to somehow visually "stream" the changes into the files (pew-pew, Gource style), and have the visual file nodes the sizes relative to their actual sizes on disk. Perhaps we'll also have the freshly made changes to have color of the corresponding person who committed them. Files may have logarithmic size, for very big files to not obscure the whole view.

Also, I would like to set up some sort of the gravity system, so each person's avatar normally drifts somewhere in the middle of their changes (with recent changes creating more gravity).

Different files may have different colors.

File names should be pretty small and non-intrusive, unlike in Gource. But I don't want them to be absent at all, like in code_swarm.

If a file is split into several files (could happen in case of merges), we should just render several copies of the files, and eventually they'll merge in the corresponding merge commit (we should of course properly render merges). This means that we should also support a "duplicate" operation on files (in case of an actual copy, or if a branch renames a file that's being actively worked on in a separate branch).

### Visualization Parameters
- DPS, days per second: since we assing each commit a particular date (sometimes arbitrarily), time in ComIntern should flow somehow similar to how the real time goes. Though we could consider better metrics, with a better automatic time scale.
- Time for files to fade out. Should they fade out completely or just turn into smaller dormant representations of themselves?

### Questions
- Should we somehow mirror the actual directory structure via a sort of hard edges like Gource does?

## Video rendering
See [this YouTube video](https://youtu.be/0To1aYglVHE?si=C12eBNv9yHzwxZFU): basically, it seems that it's possible to send data over to ffmpeg via some sort of pipe, for it to create a video file.