For a long time I’ve disabled document recovery but have recently ren-enabled it.
Since the document recovery data is stored outside the active document directory :
AFAIK, recovery decision is “internal” to LO. It is based on ancillary files and locks which are deleted when LO terminates normally. When LO is started again, if it finds those files, then it attempts recovery with an auto backup file stored in its user-private directory.
It does not consider any other document. In particular, if you checked out another branch from git, resulting in a different document in your working directory, this difference is not taken into account for recovery decision. The consequence can be wrong document replacement: the recovered document belongs in another branch and it overwrites blindly the checked out one.
On the other side, if you’d like a recovery based on git history, there is no way to trigger one because LO recovery is only a (poor) protection against catastrophic events (power failure, segmentation fault, …), not an easily user-manageable feature (you’re better served with File>Save a Copy).
Note also that Git sees LO documents as binary files without any knowledge on their structure and contents. Contrary to text files, Git commits record LO files as a whole (there is no notion of “diff” for them). Replacing a single character by another one, not changing file byte length, nor changing formatting nor any other attribute, will cause the full file to be reentered into the repository on next commit.
As a conclusion, Git and LO are two independent worlds.
will cause the full file to be reentered into the repository on next commit
It depends… first yes, but on the next run of git gc (which also may happen automatically) the change will be compressed and you end up with less disk space consumed than the multiple copies of the file consumed before.