Re: Transparently encrypt repository contents with GPG

Michael J Gruber <git@drmicha.warpmail.net> writes:

Smudged one can never be authoritative. That is the whole point of smudge filter and in general the whole convert_to_working_tree() infrastructure. It changes depending on who you are (e.g. on what platform you are on). So running comparison between two clean versions is the only sane thing to do.

You could argue textconv should work on smudged contents or on clean contents before smudging. As long as it is done consistently, I do not care either way too deeply, as its output is not supposed to be used for anything but human consumption. Two equally sane arrangement would be:

 (1) Start from two clean contents (run convert_to_git() if contents were
     obtained from the work tree), run textconv, run diff, and output the
     result literally; or

 (2) Start from two smudged contents (run convert_to_working_tree() for
     contents taken from the repository), run textconv, run diff, and
     run clean before sending the result to the output.

The former assumes a textconv filter that wants to work on clean contents, the latter for a one that expects smudged input. I probably would suggest going the former approach, as it is consistent with the general principle in other parts of the system (the internal processing happens on clean contents).

Both of the above two assumes that the output should come in clean form; it is consistent with the way normal diff is generated for consumption by git-apply. You can certainly argue that the final output should be in smudged form when textconv is used, as it is purely for human consumption, and is not even supposed to be fed to apply.