| What you need is a "git rebase" that records a second parent for each commit pointing to the original commit that is being rebased. People who prefer git rebase workflow will hate the complicated history they see in "git log", but otherwise it will be the same. Alternatively, the right way to use "git merge" is to merge every successive commit of a branch one by one. The problem with "git merge" is that it collapses multiple commits into one giant patch bomb. If one of the commits caused a problem, you don't have that commit isolated on the relevant stream (the trunk) where you are actually debugging the problem. You know that the merge introduced a problem, and it seems that it was a particular commit there. But you don't have that commit by itself in the stream where you are working. It can easily be that a commit which worked fine on a branch only becomes a problem in its merged form on the trunk, due to some way a conflict was resolved or whatever other coincidence or situation. Then, all you know is that the giant merge bomb caused a problem, but when you switch to the branch, the problem does not reproduce and thus cannot be traced to a commit. If that commit is individually brought into the trunk, the breakage associated with it will be correctly attributed to it. In both cases, the source material the same: the original version of the commit doesn't exhibit the problem on its original branch. It is pretty important to merge the individual changes one by one, so that you are changing fewer things in one commit. People like rebase because it does that one by one thing. Git rebase breaks the relationship by not recording the extra parents, but since they have the reworked version of each change on the stream they care about, they don't care about that. Plus they like the tidy linear history. |