search

AGWA / git-crypt

Transparent file encryption in git
https://www.agwa.name/projects/git-crypt/
GNU General Public License v3.0
8.21k stars 476 forks source link

git filter-branch reports unstaged changes #87

Open gedl opened 8 years ago

gedl commented 8 years ago

I can't be sure this is due to git-crypt, but I've never experienced this before. Steps to replicate:

Expected results:

Actual result: error message Cannot rewrite branches: You have unstaged changes.

git status returns 

On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
nothing to commit, working directory clean

Anybody else experiencing this issue ?

I reiterate that I might be wrong, and this might not be due to git-crypt, but I can't think of any other cause.

alerque commented 8 years ago

Did you have anything in the attributes file at any point int history such as smudge/clean filters (whether git-crypt related or not)?

gedl commented 8 years ago

Hi @alerque

I never had such filters.

I eventually ran the filter-branch command successfully by git-crypt locking the repo. After running the filter-branch, I unlocked the repo and everything was fine.

This strengthened my suspicion about git-crypt causing this strange behaviour.

alerque commented 8 years ago

Okay that makes sense now. So the way git-crypt works is with smudge/clean filters that transform the encrypted version (stored in the repo) into a plain version (which you see in your working copy). If you remove the information git uses to know how (and when) to do this transformation, then it's going to notice that the copy of the file checked out in your working copy is not the same as in the repo. This is to be expected. Locking the repo checks out the raw (encrypted) file as saved in the repo, so then deleting gits meta data no longer causes it to see a change that it didn't make.

Perhaps this could be better documented, but the behavior itself is by design.

gedl commented 8 years ago

Yes, it makes sense. And agree that this is a documentation fix. I couldn't figure it out myself, but it makes all the sense. Maybe a line or two in the documentation would have avoided opening this case in the first place.

Thanks for the reply !

Gonçalo Luiz

On 7 June 2016 at 15:26, Caleb Maclennan notifications@github.com wrote:

Okay that makes sense now. So the way git-crypt works is with smudge/clean filters that transform the encrypted version (stored in the repo) into a plain version (which you see in your working copy). If you remove the information git uses to know how (and when) to do this transformation, then it's going to notice that the copy of the file checked out in your working copy is not the same as in the repo. This is to be expected. Locking the repo checks out the raw (encrypted) file as saved in the repo, so then deleting gits meta data no longer causes it to see a change that it didn't make.

Perhaps this could be better documented, but the behavior itself is by design.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AGWA/git-crypt/issues/87#issuecomment-224297250, or mute the thread https://github.com/notifications/unsubscribe/AFPBTmfJ8Ydi-dVUbNef5_GdsWUKGr1sks5qJX-GgaJpZM4IubzK .