3 ms·
I don't think octopus merges or most merges in the Linux kernel are related to the point the article is making, or the workflow GitHub encourages. I'm not sayin
by Sir_Cmpwn 8y ago
I don't think octopus merges or most merges in the Linux kernel are related to the point the article is making, or the workflow GitHub encourages. I'm not saying you should never merge, I said:
>You should only use merging to merge two divergent or unrelated histories.
- WorldMaker 8y agoMerge history can be useful history in source control. Rebases and cherry picks just hide merges, sweeping them under the rug, sometimes making them extremely hard to spot when they go wrong, and even harder to fix down the line when it causes the next merger to go wrong (as this article series works to show in explicit examples). It's better to merge often and rarely if ever allow two branches to even have "divergent or unrelated histories".
- Sir_Cmpwn 8y agoThe conflicts shown in the article are generally solved by rebasing and are not any different from a merge conflict. If the changes which caused them represent divergences in genuinely separate histories, then a merge makes sense. >It's better to merge often and rarely if ever allow two branches to even have "divergent or unrelated histories". Remember that git is distributed, not just nominally but also in workflow.