On Sat, Dec 27, 2008 at 8:02 AM, "Peter Valdemar Mørch (Lists)" wrote:
quoted text
>
> * 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.

quoted text
> 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?

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html