-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
git reports files changed when there are no changes #127
Comments
This one occured to us since about two or three weeks ago.
|
Which git version? I'm guessing #37 is back maybe due to a newer git. Also could you please copy-paste an exact output of transcrypt? It's always good to iron out that we're taking about the same thing. |
I misread. You're saying it's 100% git. |
FWIW, I'm getting same the issue. I'm checking out #37 now. Git version: git version 2.24.3 (Apple Git-128) |
I keep getting the following anytime I run a git command:
I also can't get unchanged files to say they're unchanged. |
UPDATE: I resolved this by overwriting the Xcode-packaged git w/ Homebrew. Now I'm on git 2.34.1 and all is good. |
@coxjc See #59 concerning those (annoying) warnings. I suspect fixing this might cause breakage. I have had this problem - changes when there are no changed files - occur through a number of versions of git. Typically after I pull changes from other developers. It might be caused be differences between development environments between different developers. Once I fix the problem - e.g. by committing the "unchanged" files I can't get it to reoccur again on demand. |
Could anyone experiencing this issue try the latest pre-release version of transcrypt from the The fix for #37 (PR #109) was merged back in April 2021 but we haven't cut a release since 2.1 in September 2020, so there's a chance the pre-release version on Or manually run |
I have the following version of transcrypt, which I believe is the latest in main:
I removed the untracked files from the output, these are expected and not related.
If I run the suggested command I get:
But the output of In this particular case it means I can't run the "git pull" on the repo, because git incorrectly thinks the local files conflict:
Similarly, I cannot run other commands such as rebase.
Same goes with I have kept a copy of the working dir, so can run any other commands you want me to. My theory is that the files were committed by another developer, and as a result there might be something different about the encryption or encoding or something that is confusing transcrypt. |
Thanks for the detailed report @brianmay. I appreciate all the reports and feedback here into what is an annoying and difficult to reproduce issue. Unfortunately I only have some guesswork to offer in response, but it's worth looking into especially since it aligns with your suspicions about there being "something different" about commits from another developer. In issue #118 @Aramgutang found, documented, and fixed an edge case bug in Transcrypt where a partial commit of a transcrypt-ed file on one machine would cause these kinds of symptoms on another machine. For Git client tools that permit a partial commit of transcrypt-ed files, the bug would cause the original committing machine to generate an incorrect salt from that machine's file on disk, instead of from the partially-changed file bytes actually being committed. Most Git clients do not (and should not) allow partial commits of the secret files, but some do, in particular the very popular VSCode. The explanation in issue #118 is much better, I encourage you to go and read it. Even though you are indeed using the latest Can you check with the developer who committed the changes causing your problem whether:
If both of these are the case, it could explain why you keep seeing this problem. And if that bug is indeed the cause, getting all devs on your project to use the |
Other developer on leave until February, will follow-up then. |
I had the same issue, I was able to fix it by uninstalling OpenSSL (my version was |
I have a suspicion this might be still occurring for me too, but my coworker is rather busy, and haven't been able to confirm what version he is using yet. |
I've been encountering this for a few weeks now and finally associated the phantom changes with Transcrypt, which lead me here. Investigation ongoing, I too seem to only encounter this when files are changed by other developers.
|
@emcniece Are you able to confirm if the other developers are using the same version? |
Indeed, they report:
Fairly sure they're on OSX 12. |
Hi, if anyone here is suffering from the compatibility bug with MacOS Ventura and has some time, I'd appreciate it if you could run some tests for me on your system(s) and give me feedback to help isolate the lingering bugs – please see instructions in my comment #147 (comment) Thanks! |
For anyone experiencing phantom file changes recently – and where anyone committing to the repository has been using transcrypt version 2.2.0 with MacOS 13 Ventura (or with LibreSSL 3+ in general) – please upgrade to the new 2.2.1 release of transcrypt across all your repositories. You may still see phantom changes after the upgrade, but re-committing the phantom changed file should fix it once and for all. More info here (#147) |
we are seeing this with transcrypt 2.3.0. We are upgrading from transcrypt 1.1.0 and everyone uses LibreSSL 3. I can upgrade the repo to 2.3.0 but the next person that clones the repo and runs transcrypt 2.3.0 to setup the repo on their machine can see some of the phantom files. Recommitting them does seem to work for their cloned repo, but then the next person has the same issue, etc. Is there a recommended path we should be doing this maybe? It doesnt always show up, but sometimes. I am worried we have branches open with secrets from v1.1.0 when we upgrade to v2.3.0 that we will see this. Should we be closing those branches maybe and not try to use them in 2.3.0? I was hoping everyone could just do a |
I got fed up with this issue after not finding a permanent solution for many years. In the end I switched to git-crypt which works fine. |
I think I wouldn't trust the security of transcrypt anymore, see #126 #162 etc. transcrypt is good in that it will work with any file type, and produce good diffs. But not so good in that secrets are left in plain text in the working tree. And uses known insecure encryption. Some alternatives, depending on what you are trying to do, include:
Another approach entirely is to store the secrets on a server, and retrieve them as required.
|
Hi @twrally I think you are experiencing problems due to upgrading major versions from 1.x to 2.x. There was a bug fix for salt generation in the version 2.0.0 release from over 5 years ago that requires re-encryption and a simultaneous upgrade by all users to avoid issues with persistent changed files. This fix was a breaking change and more painful that the usual upgrade path, as you are finding. These steps should fix the issue and get your team back to a consistent, working setup:
Unfortunately transcrypt's |
I have had this often happen. And it kind of makes transcrypt very difficult to use, as git thinks the work tree is not clean.
The files in question were never modified locally.
A work around seems to be to commit the non-existent changes anyway, but that doesn't appear to be a good a long term solution. Eventually it will happen again.
The text was updated successfully, but these errors were encountered: