Facade spikes memory use when run on large repos or large commits (by bytes)

> [!NOTE]
> Migrated from [augurlabs/augur#3593](https://github.com/augurlabs/augur/issues/3593)
> Originally opened by `@MoralCode` on 2026-01-16

---

While we already introduced fixes to batch the processing of tasks to limit the impact of a large _repo_ (lots of commits) we arent accounting for repos with large commits or large repos (by number of bytes).

Examples of repos (thanks to @cdolfi for sharing these on slack)
- https://github.com/apache/airflow-site-archive - only 151 total commits, but a lot of them look like this: https://github.com/apache/airflow-site-archive/commit/c1655a99cdcb97ea2493191befea3d83c5baeb50
- https://github.com/backstage/upgrade-helper-diff - only 432 commits but with https://github.com/backstage/upgrade-helper-diff/commit/b55913faed826dad73db2a8aee9ada1076e54035

the apache airflow repo itself is 37 gigabytes cloned for example

```
$ git format-patch --stdout c1655a99cdcb97ea2493191befea3d83c5baeb50^..c1655
a99cdcb97ea2493191befea3d83c5baeb50 | wc -c
16974787
```
And this one commit in that repo is 16 MB. And it doesnt even have any/many binary files in it

Offending task: analyze commits in parallel

There are two points in the code where lots of memory is getting used, one being

https://github.com/chaoss/augur/blob/8ec768dac20841db1f625d3b3b0c154ad88dec4f/augur/tasks/git/util/facade_worker/facade_worker/analyzecommit.py#L162

and the other (arguably more egregious because this is where it gets used so aggressively quickly):

https://github.com/chaoss/augur/blob/8ec768dac20841db1f625d3b3b0c154ad88dec4f/augur/tasks/git/util/facade_worker/facade_worker/analyzecommit.py#L197

I think ultimately we need a better way to extract data from git commits than reading output from the git CLI, but that is going to require a lot of maintainer buy in for something so major.

For this issue, i want to reduce the impact of this handling of output from the git CLI as much as possible. We definitely should be trying to:
- not copy the probably already large amount of data into new variables
- maybe find a way to handle this data in chunks and/or compress it down to just what we need
- making as small of changes to the code as possible, since this is pretty important code