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
Attachment:
signature.asc
Description: PGP signature
