On Jul 31, 2014, at 7:43 PM, brian m. carlson <sand...@crustytoothpaste.net> wrote: > > You're not the first person to be surprised by the way merge works.
I’m not the first, because the merge command is broken. Once fixed, I would be happy to be the last. Until then, the bug remains unfixed. I’m sending the mail to petition for this bug to be fixed. > From the git-merge manage: > > [This behavior] occurs because only the heads and the merge base are > considered when performing a merge, not the individual commits. From: google(”git merge”): > git-merge - Join two or more development histories together Either, the command should do as documented, or be fixed. In that reference, there is no mention that merge will not merge. There is no mention that merge isn’t the command I want to merge, but that I should use rebase. Further, google(“git rebase”) says: > There is no difference in the end product of the integration, Clearly, this is a lie. There is a difference. Now, about rebase: > Do not rebase commits that you have pushed to a public repository. > > If you follow that guideline, you’ll be fine. If you don’t, people will hate > you, and you’ll be scorned by friends and family. Since everything I do goes up and down into repositories and I don’t want my friends and family to scorn me, rebase isn’t the command I want to use. I want to use the simple, it works, named for the operation I want to perform, merge. I’m a simple user, and the simple command I want to work. You can name the old merge command, merge-mostly or merge-fast and the new one can be called merge. > (That was added after 1.7.9.5.) I don’t want bugs documented, I want them fixed. I’m not reporting a doc bug, the doc is correct. > If you want the behavior of applying multiple patches in a row, you want > to use git rebase, not git merge. Since rebase re-applies the patches > of each of your commits on top of another branch, the identical change > won't cause conflicts. But, I don’t want the series of patches, I just want a simple, merged feature X on trunk single commit that merge does. Given branch B, master M, and cherry picked C, what I want merged is B-(M+C), not B-M. The problem with B-M, is that when you do B += C (aka cherry pick from master onto your branch), then M += B-M (merge your branch into master), that C is then replicated. This replication is wrong, always wrong, never right, incorrect, broken. This is the bug I want fixed.-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
