Question for the git rebase experts

Question

git

I have 2 branches: master and newdesign (which is split from master). They develop in parallel, i.e. each has its own variations. At some point in the newdesign branch, I ran the git rebase master command to pull the changes, merged and committed everything. Now more time has passed and I'm doing a git rebase master again on the newdesign branch. Why does git start merging everything again from the very beginning, and not from where I left off with the last rebase? And how to force it to start from that place?

Thanks in advance for your help

Answer 1

Here's what happens during a rebase:
1. Git rolls back all your commits to newdesign.
2. Moves the newdesign pointer to the same location as master points to.
3. Rolls your commits one at a time, like patches.
Now about conflicts.
1. Let's say one of your C commits made a change in the a() method of class A, and the same method changed in master.
When you rebase and it comes to applying commit C in step 3, there is a conflict. You enable it and call git rebase --continue. At this point, it's not commit C that applies, it's commit + your conflict resolution changes. That is, a certain C' is created, which is actually completely different than C, since it contains not only a patch of your initial changes, but also conflict resolution.
2. So, you have completed this rebase, continue to work further, and others continue to hotfix in master.
2.1. Let's say the A#a() method was no longer touched in master. Then at the next rebase, all your commits will be rolled back, the pointer will move to the new master position, and the commits will be applied one by one. And when it comes to commit C', it will be applied without conflicts , because it contains the total changes: yours + resolving conflicts with the master.
2.2. Now let's say that the A#a() method was changed again in master. Then, when rolling forward commit C', there will be a conflict: you have some changes (yours + your conflict resolution), and there are others. Therefore, you will have to resolve conflicts again and create C'' already.
Apparently, you are faced with situation 2.2.
But keep in mind that the same will happen if you do merge instead of rebase: conflicts arose after the previous merge. And nothing can be done about it - these are new conflicts with new changes.
Here is an example of a situation on a test project: gist.github.com/klikh/e72940fcfa23ad90f3ca
First, at the first rebase, situation 1 (first conflict), then at the second rebase there are no conflicts (2.1), then at the third rebase there is a conflict, but with new changes in master(2.2).
I hope it becomes clearer, if anything, ask.

Answer 2

I don't know the answer, but I'll subscribe.
PS UFO, why does the "subscribe to answers" checkbox appear only after the first comment?

Answer 3

There is such a thing - git rerere- you can try to use it. Well, there is always the good old merge.

Answer 4

Er... well, that's right, what you do is what you get. With rebase, no merging occurs, the newdesign branch remains the same length as it was, obviously, only rearranged to the top of master. The next time, of course, this entire branch from its first commit is rearranged again, etc.

Answer 5

During the rebase, I manually resolve conflicts in some files. Look, we have master - this is production, and newdesign - a new version that is in development. In the master, fixes and updates for production are now taking place, and in newdesign, the new version itself is being developed. Here from time to time I want to merge changes from the master in newdesign with the help of rebase. I switch to the newdesign branch and do a git rebase master there. And every time I do that, I have to resolve all conflicts starting with the first revision of newdesign. And I want to resolve each time only newly appeared conflicts after the previous rebase