[[!comment format=mdwn
 username="spwhitton"
 avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
 subject="comment 4"
 date="2017-04-05T22:28:10Z"
 content="""
git-remote-gcrypt maintainer here.

As Joey recommends for the meantime, I am successfully using an `rsync://` gcrypt remote plus a separate encrypted git-annex rsync remote to work around these performance issues.

git-remote-gcrypt relies on rsync to implement the incremental upload, so the README is wrong to suggest that using an `sftp://` remote would work around this issue -- git-remote-gcrypt invokes curl for the sftp transaction, which as far as I know does nothing incremental (that's presumably why rsync exists).  I've just updated the README.

If we wanted the gitception gcrypt remote to be incremental, we would need to implement rsync-like incremental uploads on top of the structure of git commits, such that we could push a git commit that represents the changes to the gcrypt packfiles and manifest since the previous commit.  But I don't think this is possible for binary files -- I don't think git can represent the deltas efficiently.

I've come to think that git-remote-gcrypt's gitception mode is not actually very useful, simply due to the design of git.  But perhaps there is an alternative way to represent the manifest and packfiles that would be compatible with incremental git pushes.
"""]]