Hello Elijah, Thank you for reply. I guess the simpler explanation of what is happened would be the following: Let's say there are three commits: add_c1, del_c2 and add_c3. When they go like this "add_c1 + del_c2 + add_c3" at the end of execution you end up with 2.cpp. That is the case before I do rebase. When I change the order of commits into "add_c3 + add_c1 + del_c2" (the case when I do rebase), I end up with no 2.cpp as add_c1 after add_c3 does nothing, because the file already exists. However, would be great for Git to return an error that it cannot create one more file. That is probably would be the best solution to this issue. If I change the order of execution using the braces like in math into "add_c3 + (add_c1 + del_c2)", then Git first executes the content of braces and that expression gives me a no-op (first rebase), then it executes "add_c3 + no-op" (the second rebase). That gives me a 2.cpp at the end. That is why it works as expected when I first merge del_c2 into add_c1 and at the end I move add_c3 before add_c1. Best regards Dima ________________________________________ From: Elijah Newren <newren@xxxxxxxxx> Sent: Thursday, July 4, 2024 11:03 PM To: Dmytro Ovdiienko <Dmytro.Ovdiienko@xxxxxxxxxxxx> Cc: git@xxxxxxxxxxxxxxx <git@xxxxxxxxxxxxxxx> Subject: Re: Losing the file during rebase [You don't often get email from newren@xxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] CAUTION: [EXTERNAL Email] 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. Please access the attached hyperlink for an important electronic communications disclaimer:https://dashfinancial.com/disclaimer<https://dashfinancial.com/disclaimer/>
