[FEATURE] Add option to create a shallow clone with a truncated history

[sza-1]

Is your feature request related to a problem? Please describe.
It seems that currently Password Store creates a full clone of the repository including all previous Git commits (even thought this history is not used by Password Store). I believe that smartphone is not a primary device to work with pass repo, so a full repo history is not necessary there. A smartphone is just a lightweight terminal to access to the latest repo commit. So I want to reduce attack area in case of loosing the smartphone by setting an option to force Password Store to create a shallow clone only (--depth 1 or --depth N in Git). The previous commits can contain a lot of extra information in file names and descriptions even thought these files were removed from HEAD.

(Also it would be nice to have an option to force Password Store to force fetch repo every time the app started and lock this option. So if a desktop user removed smartphone's GPG key from .gpg-id and re-encrypted repo then Password Store on the lost smartphone will fetch the latest commit only and can not decrypt it anymore with the device's GPG key. But, perhaps, this idea is for the other ticket.)

Describe the solution you'd like
Password Store should have ability to specify clone depth (--depth 1 or even customized --depth N) and use it on fetch.

[msfjarvis]

This is an extremely niche use-case that I don't find convincing enough to add yet another user-facing option for. APS when used with a sufficiently modern smartphone is secure enough to not require snake oil mitigations like stripping Git history.

[plant7403]

@CrazyH pretty good point actually, not sure if this is possible and it doesn't have any drawbacks
And I think additional security would be good in any case

[sza-1]

@CrazyH pretty good point actually, not sure if this is possible and it doesn't have any drawbacks
And I think additional security would be good in any case

Yeah, at least it should help saving some space in case of using old and huge repo. :)

[sza-1]

Actually I found an alternative solution: do not share the primary repo with APS and give it access to the secondary, stripped, password repo only.