-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
Squash commits do not remember if the file was just removed from being cached #18331
Comments
Thanks for the detailed report and reproduction steps @EmosewaMC. I'm sorry to hear about the issues you encountered. I got around to testing this and was unable to reproduce the behavior by following the steps you shared. I had three commits I squashed down to one, and the README.md file I had created and previously committed remained as an untracked file. Have you been able to consistently reproduce this? Is there anything I could be missing? |
https://www.youtube.com/watch?v=U_M_4ZkUZ4U |
now I would like to add, if I used the next commit back from the one i selected to merge with, github desktop would infinitely error on the squash and print out an error i couldnt see and I believe these are them in the logs
this is on version 3.3.12 fwiw |
The problem
Hi,
I have after experiencing the bug on a repo with a ton of work, that a combination of squash commits via github desktop and
git rm --cached <file>
results in, instead of the file just being untracked as was done in the original command, the file is deleted. This caused me to lose around 15 hours of work and I am going to just cut my losses and report this as an issue, and do the work again (at least i know what to do now, maybe it'll be faster)Release version
Version 3.3.11 (x64)
Operating system
Windows 10
Steps to reproduce the behavior
git rm --cached <file>
, commit and push via github desktopLog files
Will provide as needed in private.
Screenshots
No response
Additional context
May not be a bug with desktop, but when github desktop told me in reasons I cannot squash commits that are themselves squashes, that the squash replays the commits up until that point, I would assume it remembered the what and why of the commit, not just the what.
The text was updated successfully, but these errors were encountered: