5 ms·
You should only use merging to merge two divergent or unrelated histories. Merging should be a tool you use infrequently. GitHub has trained you to do it wrong.
by Sir_Cmpwn 8y ago
You should only use merging to merge two divergent or unrelated histories. Merging should be a tool you use infrequently. GitHub has trained you to do it wrong.
- elcomet 8y agoWould you care to add more details? Are you saying that id you use some workflow like one branch / one feature, you should usually rebase? Almost all branches have related history, it is very rare to have completely unrelated branches with separate starting points.
- Blackthorn 8y agoGithub is respecting the original intention of git. For a long time it didn't even have cherry-pick functionality.
- Sir_Cmpwn 8y agoCitation needed. So far as I can tell from reviewing git's source code, cherry-pick was there since at least September 2005, after which the trail runs cold because of a big refactor. Git's first release was in April 2005.
- akerl_ 8y agoWhy wouldn't I want to merge?
- Sir_Cmpwn 8y agoIt makes a merge commit which is usually unnecessary. If there were no conflicts, there's no need to have a commit fixing them up. If you just want to know who integrated the patch, git stores the author and committer fields separately. Most git users in touch with the design goals of git use branches sparingly, either for long lived projects (with hundreds of commits) or as a sandbox in which work is frequently rebased into a concise history of a few patches, which are usually integrated upstream without a merge. Merges are also used to merge disparate trees, like when Linus merges in trees from around the kernel development scene (since each kernel subsystem maintains their kernel tree as almost independent projects, using merge makes sense to integrate the foreign histories into the upstream kernel). The Linux kernel approach probably requires a full-length article to fully explain, though, so don't read too much into that.
- Steltek 8y agoI would argue the "design goals" of git have evolved far past the kernel, which is a very unique and special project. These new patterns don't seem to invalidate how the kernel uses git and they offer a lot of ergonomics in a Github-styled atmosphere. Are the only downsides that 1) users don't understand how kernel development is done, which extends far beyond source control; and 2) a merge commit is left as a marker?
- Sir_Cmpwn 8y agoIt's not really about the kernel, the kernel is just where the world's most talented git experts work. The downsides include the creation of a merge commit, sure, but also the fact that it's used as a crutch by users who would rather not strive to understand how git works.
- WorldMaker 8y agoGit uses a DAG for multiple reasons. Avoiding merge commits is ignoring most of the power of having a DAG for data structure. The Linux Kernel repo itself has some fascinating examples of DAG usage, including some of the most well known "octopus" merges with many more than two merge parents.
- Sir_Cmpwn 8y agoI 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".