| |||||||||||||
pull --rebasepull --rebasePosted Mar 21, 2012 15:42 UTC (Wed) by misiu_mp (guest, #41936)In reply to: pull --rebase by adobriyan Parent article: Git project seeks discussion on "push" change
Yes, you should test the code after a rebase as well as after a merge, but,
as we all know testing is not always bullet proof.
Part of the testing is code review, including the one you do when you modify the existing code.
A - B - C - D - H
\ /
F - G
you implement a feature (F, G) starting from version B.
In order to implement the feature, you have to investigate and understand how the existing code works. When you do that you see version B and the history above accurately depicts it. Now imagine C introduces a change that affects the code you analyzed in a logical, non-trivial way (that does not introduce a merge conflict with your feature). Your feature will now behave incorrectly, but in a very subtle way. If you based your feature off C or D, you would have probably analyzed the code correctly and made a correct implementation. But you didn't. You maybe just quickly review the changes in C and D, run tests and push to H, merging without conflicts. The tests didn't pick up the subtle error and you've got a bastard-of-a-bug, which depends on a simultaneous modification in two branches, but not in each separately. If you rebase, the other branch disappears and the history looks as if you indeed started your work after C, indicating you should have seen the changed behavior and its code. A - B - C - D - F - GAfter the bug was found it will be much more difficult for anyone, including you to realize what happened. The lack of rebasing would not prevent the bug, but it would make it easier to track and fix.
(Log in to post comments)
|
|||||||||||||