On Thu, Jul 4, 2024 at 7:29 AM Dmytro Ovdiienko <Dmytro.Ovdiienko@xxxxxxxxxxxx> wrote: > > Hello, > > I'd like to report an issue. I'm not sure if it is a bug. Git just behaves not in the way as I expected. > > $ git --version > git version 2.34.1 > > > The problem is that Git is losing the file when I do rebase. Following are the steps to reproduce the issue: > > 1. mkdir test > 2. cd test > 3. git init > 4. touch 1.cpp > 5. git add 1.cpp > 6. git commit -m "Added 1.cpp" > 7. touch 2.cpp > 8. touch 3.cpp > 9. git add 2.cpp 3.cpp > 10. git commit -m "Added 2.cpp and 3.cpp" > 11. git restore --source @~1 2.cpp > 12. git add -u > 13. git commit -m "Delete committed 2.cpp" > 14. git revert @ > 15. git rebase -i @~3 > 16. Now in the opened editor > a. move the last commit (revert commit) to the top of the commits list > b. squash/embed (by typing 'f') the "Delete comitted 2.cpp" commit into the commit "Added 2.cpp and 3.cpp" > 17. Save and exit > 18. ls > > The output is : 1.cpp 3.cpp > Expected: 1.cpp 2.cpp 3.cpp > > > In case if at the step #16 you first do 16b, then close the editor, then start rebase again and do 16a, then all the files are on their places. Not a bug; I think you are expecting patches & commits to commute, when they do not. One way to look at this, which I think you are viewing it from, is: * If you start with 2.cpp, then remove 2.cpp in a commit, then restore it in another commit, then you end up with 2.cpp; it _appears_ the last two commits are just inverses and together do nothing. And similarly, * If you start with no file, then add 2.cpp in a commit, then remove it in another commit, then you end up with no file; it _appears_ the last two commits are just inverses and do nothing. However, if we take the last two commits above for each scenario but give it a different starting point: * If you start with no file, and try to play a change to remove 2.cpp (which already doesn't exist), and then add 2.cpp, then the first commit is a no-op that does nothing while the second adds 2.cpp. The last two commits are clearly not inverses. * If you start with 2.cpp, then add a change which also tries to create the same 2.cpp, and then remove 2.cpp, then the first commit is a no-op that does nothing while the second removes 2.cpp. The last two commits are clearly not inverses. When you tried to rebase and swap the order of commits, you took things from one of the first scenarios to one of the last two scenarios.
