On Wed, Sep 21, 2022 at 11:22:19PM -0700, Ronny Forberger wrote: > > I solved it like this: > > > > .git/config: > > > > [filter "crypt"] > > clean = openssl enc -pbkdf2 -iter 10000 -aes-256-cbc -in %f && > > shred %f > > smudge = openssl enc -d -pbkdf2 -iter 10000 -aes-256-cbc > > required > > > > .gitattributes > > * filter=crypt [...] > But I still have a problem: > > The clean filter seems to be run on git pull as well. Any ideas how to > bypass this? >
I can only provide an educated guess. `git pull` is basically `git fetch` plus `git merge` (or `git rebase` - depending on the command-line options). Only `git merge` or `git rebase` want to look at the work tree, and they might do so in order to detect whether it is "clean" in the sense it does not contain any unstaged changes. When no smudge/clean trickery is involved, Git might rely on the "stat" information obtained for the files in the woek tree: if the modification time (and the size) of a file do not differ from those recorded in the index, the file might be deemed to be unchanged; but if they differ, Git has to go out of its way and calculate the hash sum of the contents of the file in the work tree and compare it with the one recorded in the index. So, my guess is that when clean/smudge is involved, Git might be forced to calculate the hash each time (or may be just after the first checkout?), and that requires obtaining "clean" blobs which, in turn, requires running the clean filter on them. You could experiment with this hypothesis running various operations which should logically require checking the work tree status while having GIT_TRACE=1 in the environment - so see which commands get actually invoked. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20220922093816.ke7hsw756as77v4u%40carbon.
