Losing the file during rebase

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<https://dashfinancial.com/disclaimer/>

On Thu, Jul 4, 2024 at 7:29 AM Dmytro Ovdiienko <Dmytro.Ovdiienko@iongroup.com> wrote:

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.

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@gmail.com>
Sent: Thursday, July 4, 2024 11:03 PM
To: Dmytro Ovdiienko <Dmytro.Ovdiienko@iongroup.com>
Cc: git@vger.kernel.org <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 <Dmytro.Ovdiienko@iongroup.com> wrote:

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/>

On 2024-07-04 at 21:45:25, Dmytro Ovdiienko wrote:

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.