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