What is the danger of rebase, or how did it happen that 2 * 3 = 5
Once, a senior programmer Anton was looking for the cause of another bug in a very important project of the company:
The company used rebase, the commit history was linear, and it was a pleasure to search Anton.
- Yeah, I found it. Well, of course: the code says "2 * 3 = 5", even if it worked with this nonsense! Which one
Anton: - Hey, Vasily! What were you thinking when “2 * 3 = 5” wrote?
Vasya: - Yes, there was no such thing. I wrote “2 + 3 = 5”, I remember exactly.
Anton: - You wrote in the message to the “2 + 3” commit, but in the “2 * 3” code, look.
Vasya looked at his commit, and did not believe his eyes: indeed, in the code “2 * 3 = 5”. It’s darkened in Vasya’s eyes ...
Anton: - Eh, you can’t be so irresponsible, Vasily, this is unacceptable.
Vasya had to be fired ...
Anton is looking for the cause of the next bug in a very important project. The company uses merge, not rebase, the commit history is non-linear, so Anton frowns and periodically swears, looking at the web of merged branches. But git bisect can work with non-linear history and it doesn’t bother him at all.
- Yeah, I found it. In the code "2 * 3 = 5", it would still work. So, it appeared when 2 branches were merged. In one, Vasya adds “2+ 3 = 5 ”, he wrote everything correctly, and we should have the result of operation 5 according to TK. And in another Petya multiplies “2 * 2 = 4”. Yeah, but at the merger it turned out "2 * 3 = 5", of course.
Anton: - Hey Peter! Why did you replace addition to a work?
Petya: - Well, it seemed to me more visual.
Anton: - Roll back, we got a bug because of this.
Petya: - OK.
Moral : rebase changes the context in which commits were written, and loses information about branch merges, which may be useful to determine the cause of the error. Remember this.
Sample project on github .
Upd.
If you want to reproduce, note that the project specifically uses a format slightly different from “2 + 2 = 4 (in the column)”, so that both merge and rebase pass without conflict.
git bisect start
git bisect bad
git bisect good
…
The company used rebase, the commit history was linear, and it was a pleasure to search Anton.
- Yeah, I found it. Well, of course: the code says "2 * 3 = 5", even if it worked with this nonsense! Which one
@#$%^
did you write? Anton: - Hey, Vasily! What were you thinking when “2 * 3 = 5” wrote?
Vasya: - Yes, there was no such thing. I wrote “2 + 3 = 5”, I remember exactly.
Anton: - You wrote in the message to the “2 + 3” commit, but in the “2 * 3” code, look.
Vasya looked at his commit, and did not believe his eyes: indeed, in the code “2 * 3 = 5”. It’s darkened in Vasya’s eyes ...
Anton: - Eh, you can’t be so irresponsible, Vasily, this is unacceptable.
Vasya had to be fired ...
At this time in parallel reality ..
Anton is looking for the cause of the next bug in a very important project. The company uses merge, not rebase, the commit history is non-linear, so Anton frowns and periodically swears, looking at the web of merged branches. But git bisect can work with non-linear history and it doesn’t bother him at all.
- Yeah, I found it. In the code "2 * 3 = 5", it would still work. So, it appeared when 2 branches were merged. In one, Vasya adds “2+ 3 = 5 ”, he wrote everything correctly, and we should have the result of operation 5 according to TK. And in another Petya multiplies “2 * 2 = 4”. Yeah, but at the merger it turned out "2 * 3 = 5", of course.
Anton: - Hey Peter! Why did you replace addition to a work?
Petya: - Well, it seemed to me more visual.
Anton: - Roll back, we got a bug because of this.
Petya: - OK.
Moral : rebase changes the context in which commits were written, and loses information about branch merges, which may be useful to determine the cause of the error. Remember this.
Sample project on github .
Upd.
If you want to reproduce, note that the project specifically uses a format slightly different from “2 + 2 = 4 (in the column)”, so that both merge and rebase pass without conflict.