Re: Git (svn) merge - but ignore certain commits?

["\"Peter Valdemar Mørch (Lists)\"" <4ux6as402@sneakemail.com>]

First, a well-overdue thanks to Peter for your post.

Peter Harris git-at-peter.is-a-geek.org |Lists| wrote:
> 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?

It isn't. The whole reason for the branch was that there were 4 
"beta-level" commits on trunk/master along with a whole bunch of good 
stuff. And we wanted to add a little more good stuff, exclude the beta 
stuff and create a release.

>> 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.

I don't understand this, I'm affraid. Our "newbranch" was very short 
lived. 4 reverts and 5 commits.

What I ended up doing was to create two git branches off of svn 
"newbranch": One with all the fixes but without the reverts, and one 
with just the reverts. Do all the development on the one with the fixes, 
and then "git merge" them to both master and "gitnewbranch", then one 
with the reverts. And then git svn dcommit them both.

However *the* problem was with repeated merges: I later discovered a 
problem on the branch and need to add a commit for it to both master and 
newbranch/gitnewbranch. Aside from git cherry-pick (where I take care of 
the repeated merge problem) I still haven't found a good solution.

I ended up using git cherry-pick, and diff and patch / git diff and git 
apply. Sub-optimal. :-( But small commits! :-)

Peter
-- 
Peter Valdemar Mørch
http://www.morch.com