Add git-crypt merge driver to support secret files merging.

[shlomosh]

Add git-crypt merge driver to support secret files merging.

Update clean operation to not alter output when it run multiple times, to match recommended behaviour (https://git-scm.com/docs/gitattributes) -

For best results, clean should not alter its output further if it is run twice ("clean→clean" should be equivalent to "clean"), and multiple smudge commands should not alter clean's output ("smudge→smudge→clean" should be equivalent to "clean"). See the section on merging below.

[ahawkins]

Any movement on this PR? I just got hit by the unfortunate UX while rebasing/merging. This may fix it right?

@shlomosh should this make merge and rebase work like it does with every other file?

[tobiasBora]

I tried this pr, but it did not solve this issue, any idea why? https://github.com/AGWA/git-crypt/issues/140

[Quentin-M]

git-crypt is basically unusable without this. Is there any reason @AGWA @shlomosh this never has been merged?

[peay]

@AGWA any chance this would get merged in?

[amoffat]

I love git-crypt, but encrypting config files is a nightmare due to the inability to merge changes. Just vocalizing my support for a feature that fixes that.

[alerque]

I am along time git-crypt user, and I just started a batch of projects that I'm going to need merge for! To date I've either used it for protecting very private personal stuff in semi-private repos where I'm the only major committer and used a flat master branch, or kept secrets like deploy keys that don't typically need merging.

For the new projects I'm looking at keeping significant amounts of content that will be edited in parallel where half of it is copyrighted and half of it will be public. Rather than just making CI builds public I'd like to make the entire repository public and just lock down the files that are for some-eyes-only. If git-crypt could handle edited files being merged back and fourth it would be ideal for this scenario.

[alerque]

@amoffat Just a tip: The best architecture I've found for this is to split config files into private and public bits. Most of the time 95% of the content of config files can be unencrypted, usually only a few keys are sensitive (deploy keys, passwords, private URLs, etc.). Often there is a way to import files so that you can put just the one or two sensitive keys in an encrypted file and import it into the unencrypted config. You can often even do this programatically to set different values if the encrypted versions are not available.

In the cases where the native config syntax doesn't have a way to handle this it's usually trivial to make merging the sources part of a build or init script.

[krish7919]

You can do something similar with the https://github.com/krish7919/git-crypt-merge-tool (disclaimer, I wrote it).

Our use-case is to encrypt a file that is changed on probably every commit we make to the repo, and it works just fine.

[Quentin-M]

The worse for me is that regardless of wether we are modifying encrypted files or not, merging them or not - we can’t rebase origin/master without committing, locking then unlocking. Huge pain in big repositories.

[AGWA]

I'm curious why this PR has changed clean to pass through the file if it's already encrypted. Shouldn't the file always be decrypted, since it was passed through smudge prior to running git merge-file? Note that the proposal in #141 doesn't do this.

[AGWA]

Superseded by #180.