Hi. I understand what you mean, but if that's the case, I don't get how every file was merged successfully despite the encryption, except two of them. I thought the smudge filter was supposed to be applied to every blob before any git operation, thus exposing the clean source code. Well, in the end I've merged these two files manually. I think I might have done something wrong while branching. I'm still learning. Next time I'll be more attentive.
2016-02-08 15:32 GMT-02:00 Junio C Hamano <gits...@pobox.com>: > Leonardo <leobasi...@gmail.com> writes: > >> Hi, everybody. I'm new to git and I'd like to keep track of some codes >> we have here in our company. They have some sensitive information I >> would like to keep private. After some googling, I found some >> solutions that encrypt/decrypt the files using filters as they're >> committed/checked out. I've been using this approach and it suits my >> needs. Now I need to merge two branches, but the process is failing >> for two files in particular. First of all, here's my config file: >> >> [filter "openssl"] >> clean = openssl enc -aes-256-cbc -a -nosalt -pass pass:password >> smudge = openssl enc -d -aes-256-cbc -a -nosalt -pass pass:password >> required > > Git works on the "clean" representation of the data, i.e. the > representation of the blob object stored in the object database and > in the index, when manipulating the contents, e.g. diffing two > variants, patching (think "add -p"), merging, etc. > > As you are making the "clean" version an encrypted opaque sequence > of bytes, it is expected that you wouldn't be able to run 3-way > merges. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
