Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
After a merge I like to go through every file where conflicts were fixed and read the conflicting functions top to bottom.
-
I've seen that too. Buggy code suddenly makes a comeback. Fixes put in the code disappear out of nowhere.
-
Most think a merge works like this:
* commit 1 ... commit N from branch A
* iterate over each commit
* try to apply in branch B
It's not entirely wrong, but there is an important detail:
merge needs to find a common ancestor for the two branches A and B.
https://git-scm.com/docs/git-merge/...
As written here...
This is what git merge-base does:
https://git-scm.com/docs/...
Especially in merging large histories, it's a good idea to validate that the ancestor matches the expected one.
Another good tip: Check if the branches history was rewritten or contains reverts .
Having a close look at what commits are merged can prevent some funky results.
E.g. merging reverting commits should be double checked, cause it can happen that the revert commit undoes correct changes :) sounds like what some here described.
Related Rants
After merging 2 branches, Git randomly decided not to merge one particular line (the place where my newly defined function was called) and that caused a fixed bug to reappear. First time in 4 years I am witnessing Git do something strange like this— probably an issue in the “merge by ort strategy”.
rant
git
buggy