# Losing the file during rebase 4 messages from 2024-07-04 to 2024-07-05. Participants: Dmytro Ovdiienko, Elijah Newren, brian m. carlson. Thread: https://gitlist.dev/t/61735 ## Dmytro Ovdiienko, 2024-07-04 14:28 Subject: Losing the file during rebase Message-ID: URL: https://gitlist.dev/e/SA3PR14MB6519B74CA58C9AE49DC28513E7DE2%40SA3PR14MB6519.namprd14.prod.outlook.com ``` 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. Kind regards Dmytro Ovdiienko Please access the attached hyperlink for an important electronic communications disclaimer:https://dashfinancial.com/disclaimer ``` ## Elijah Newren, 2024-07-04 21:03 Subject: Re: Losing the file during rebase Message-ID: URL: https://gitlist.dev/e/CABPp-BGE1aDb5Nch8kQx%2BuZkCvbTz6sN0m2Yad%3D1D4%3Dz0C9JNA%40mail.gmail.com In-Reply-To: ``` On Thu, Jul 4, 2024 at 7:29 AM Dmytro Ovdiienko 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. ``` ## Dmytro Ovdiienko, 2024-07-04 21:45 Subject: Re: Losing the file during rebase Message-ID: URL: https://gitlist.dev/e/SA3PR14MB65191BDFF1F6E867969A678AE7DE2%40SA3PR14MB6519.namprd14.prod.outlook.com In-Reply-To: ``` 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 Sent: Thursday, July 4, 2024 11:03 PM To: Dmytro Ovdiienko Cc: git@vger.kernel.org Subject: Re: Losing the file during rebase [You don't often get email from newren@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] CAUTION: [EXTERNAL Email] On Thu, Jul 4, 2024 at 7:29 AM Dmytro Ovdiienko 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 ``` ## brian m. carlson, 2024-07-05 00:49 Subject: Re: Losing the file during rebase Message-ID: URL: https://gitlist.dev/e/ZodDJq_SzONsP83m%40tapette.crustytoothpaste.net In-Reply-To: ``` On 2024-07-04 at 21:45:25, Dmytro Ovdiienko wrote: > 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. Unfortunately, that would cause a lot of spurious conflicts, since one technique that many teams use to incorporate changes is to rebase them. Thus, if Alice has added file X to branch A and Bob has also added file X to branch B, and branch A gets incorporated into main, then Bob has a conflict. If the contents of the file are the same, then the user will not appreciate resolving this spurious conflict. Note that the behaviour you get for rebases is also the same one as you get for merges (which isn't exactly surprising because rebases now usually use the merge machinery). If Alice creates branch A as above and Bob creates branch B, then once A is merged into main, B won't conflict for file X. That's because if both heads in a merge contain the same file with the same blob object ID (and thus the same contents), Git short-circuits the entire merge machinery and just incorporates that version into the result, which is much faster and more efficient. It may be that you're thinking about this process as applying one patch on top of another, which is the way that the older git am-based approach used to work. However, the modern rebase functionality is designed around merges internally, since this tends to avoid the brittleness of patches (such as misapplied hunks), it's faster, and it tends to be a lot more robust in a lot of cases, including with renames. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA ```