On Sat, Dec 27, 2008 at 8:02 AM, "Peter Valdemar Mørch (Lists)" wrote: > > * And now the trick: "git merge" "gitnewbranch" back to master. But I want > to avoid the "git revert" of the few commits that weren't ready yet. > > * "git svn dcommit" master to get the new functionality into svn trunk. > > How do I "git merge" all of "gitnewbranch" except the reverts? "git rebase -i trunk" after you "git merge". Delete the lines that contain the will-be-reverted commits and the revert commits. Actually, skip the reverts in the first place to save time. Normally I wouldn't suggest it, since it will throw away your merge, but "git svn dcommit" does an implicit rebase anyway, so you will lose nothing. > Is there a way to "git merge gitnewbranch" excluding the reverts, just the > "new functionality", so the log of master doesn't even mention the reverts > and so "git svn rebase" and "git svn dcommit" work properly? If your branch is so ugly that you want to toss many of the commits anyway, maybe "git merge --squash" is what you are looking for? Or maybe you want to "git rebase -i" before merging? > How do I do this "properly"? Use many short-lived feature branches, not few long-lived generic "development" branches. Merge-and-delete is easier than herding reverts. Peter Harris -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
