{"thread":{"id":"16885","subject":"Git (svn) merge - but ignore certain commits?","startedAt":"2008-12-27T13:02:01Z","lastAt":"2009-01-08T20:00:53Z","messageCount":6,"participants":["Peter Valdemar Mørch (Lists)","Peter Harris"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"98792","messageId":"49562749.9060705@sneakemail.com","threadId":"16885","inReplyTo":null,"subject":"Git (svn) merge - but ignore certain commits?","fromName":"Peter Valdemar Mørch (Lists)","fromEmail":"4ux6as402@sneakemail.com","sentAt":"2008-12-27T13:02:01Z","receivedAt":"2008-12-27T13:02:01Z","isPatch":false,"sender":{"key":"4ux6as402@sneakemail.com","avatar":null},"body":"Hi,\n\nI'm wondering how to merge a branch back to a master/svn trunk, getting \n\"almost\" all the commits on the branch. I've experimented with \"git \nmerge -s ours\" unsuccessfully and don't know how else to proceed.\n\nBackground: Our svn trunk has had many solid commits, and a few that \naren't ready yet. We need to make a new release without these unready \ncommits but with some new functionality.\n\nExternally to git, a branch was made off of trunk's HEAD. Call it \n\"newbranch\".\n\nThe idea is to:\n\n* Create a git branch off of svn \"newbranch\", call it \"gitnewbranch\".\n\n* \"git revert\" the \"few unready\" commits on \"gitnewbranch\" so we have a \nsolid foundation\n\n* add the new functionality to \"gitnewbranch\"\n\n* \"git svn dcommit\" to get the new functionality on svn's \"newbranch\"\n\n* And now the trick: \"git merge\" \"gitnewbranch\" back to master. But I \nwant to avoid the \"git revert\" of the few commits that weren't ready yet.\n\n* \"git svn dcommit\" master to get the new functionality into svn trunk.\n\nHow do I \"git merge\" all of \"gitnewbranch\" except the reverts?\n\nI tried doing just the revert step, and then\n\"git merge -s ours gitnewbranch\"\non master, and that seemed to work. Annoyingly (to me :-D) \"git log \nmaster\" does show the reverts that happened on gitnewbranch, but the \nfiles in master were not changed. However, when I \"git svn rebase\", it \nfails with a\n\"CONFLICT (content): Merge conflict in <file>\".\nAnd hence, \"git svn dcommit\" fails too.\n\nIs there a way to \"git merge gitnewbranch\" excluding the reverts, just \nthe \"new functionality\", so the log of master doesn't even mention the \nreverts and so \"git svn rebase\" and \"git svn dcommit\" work properly?\n\nI guess I could git cherry-pick all the \"new functionality\" commits from \ngitnewbranch to master, but it sort of defeats the coolness of gits \nbranch handling if I have to keep track of the cherry-picked commits \nmanually.\n\nHow do I do this \"properly\"?\n\nPeter\n-- \nPeter Valdemar Mørch\nhttp://www.morch.com\n"},{"id":"98825","messageId":"eaa105840812271617n74406517x3335a05d224f5e0@mail.gmail.com","threadId":"16885","inReplyTo":"49562749.9060705@sneakemail.com","subject":"Re: Git (svn) merge - but ignore certain commits?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2008-12-28T00:17:25Z","receivedAt":"2008-12-28T00:17:25Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Sat, Dec 27, 2008 at 8:02 AM, \"Peter Valdemar Mørch (Lists)\" wrote:\n>\n> * And now the trick: \"git merge\" \"gitnewbranch\" back to master. But I want\n> to avoid the \"git revert\" of the few commits that weren't ready yet.\n>\n> * \"git svn dcommit\" master to get the new functionality into svn trunk.\n>\n> How do I \"git merge\" all of \"gitnewbranch\" except the reverts?\n\n\"git rebase -i trunk\" after you \"git merge\". Delete the lines that\ncontain the will-be-reverted commits and the revert commits. Actually,\nskip the reverts in the first place to save time.\n\nNormally I wouldn't suggest it, since it will throw away your merge,\nbut \"git svn dcommit\" does an implicit rebase anyway, so you will lose\nnothing.\n\n> Is there a way to \"git merge gitnewbranch\" excluding the reverts, just the\n> \"new functionality\", so the log of master doesn't even mention the reverts\n> and so \"git svn rebase\" and \"git svn dcommit\" work properly?\n\nIf your branch is so ugly that you want to toss many of the commits\nanyway, maybe \"git merge --squash\" is what you are looking for? Or\nmaybe you want to \"git rebase -i\" before merging?\n\n> How do I do this \"properly\"?\n\nUse many short-lived feature branches, not few long-lived generic\n\"development\" branches. Merge-and-delete is easier than herding\nreverts.\n\nPeter Harris\n"},{"id":"99727","messageId":"49663CA2.90102@sneakemail.com","threadId":"16885","inReplyTo":"eaa105840812271617n74406517x3335a05d224f5e0@mail.gmail.com","subject":"Re: Git (svn) merge - but ignore certain commits?","fromName":"Peter Valdemar Mørch (Lists)","fromEmail":"4ux6as402@sneakemail.com","sentAt":"2009-01-08T17:49:22Z","receivedAt":"2009-01-08T17:49:22Z","isPatch":false,"sender":{"key":"4ux6as402@sneakemail.com","avatar":null},"body":"First, a well-overdue thanks to Peter for your post.\n\nPeter Harris git-at-peter.is-a-geek.org |Lists| wrote:\n> If your branch is so ugly that you want to toss many of the commits\n> anyway, maybe \"git merge --squash\" is what you are looking for? Or\n> maybe you want to \"git rebase -i\" before merging?\n\nIt isn't. The whole reason for the branch was that there were 4 \n\"beta-level\" commits on trunk/master along with a whole bunch of good \nstuff. And we wanted to add a little more good stuff, exclude the beta \nstuff and create a release.\n\n>> How do I do this \"properly\"?\n> \n> Use many short-lived feature branches, not few long-lived generic\n> \"development\" branches. Merge-and-delete is easier than herding\n> reverts.\n\nI don't understand this, I'm affraid. Our \"newbranch\" was very short \nlived. 4 reverts and 5 commits.\n\nWhat I ended up doing was to create two git branches off of svn \n\"newbranch\": One with all the fixes but without the reverts, and one \nwith just the reverts. Do all the development on the one with the fixes, \nand then \"git merge\" them to both master and \"gitnewbranch\", then one \nwith the reverts. And then git svn dcommit them both.\n\nHowever *the* problem was with repeated merges: I later discovered a \nproblem on the branch and need to add a commit for it to both master and \nnewbranch/gitnewbranch. Aside from git cherry-pick (where I take care of \nthe repeated merge problem) I still haven't found a good solution.\n\nI ended up using git cherry-pick, and diff and patch / git diff and git \napply. Sub-optimal. :-( But small commits! :-)\n\nPeter\n-- \nPeter Valdemar Mørch\nhttp://www.morch.com\n"},{"id":"100978","messageId":"eaa105840901081029h220e06e4m1a1af693e908751e@mail.gmail.com","threadId":"16885","inReplyTo":"49663CA2.90102@sneakemail.com","subject":"Re: Git (svn) merge - but ignore certain commits?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-01-08T18:29:54Z","receivedAt":"2009-01-08T18:29:54Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Thu, Jan 8, 2009 at 12:49 PM, \"Peter Valdemar Mørch (Lists)\" wrote:\n>\n> However *the* problem was with repeated merges: I later discovered a problem\n> on the branch and need to add a commit for it to both master and\n> newbranch/gitnewbranch. Aside from git cherry-pick (where I take care of the\n> repeated merge problem) I still haven't found a good solution.\n\nWell, the real problem is that it *isn't* a repeated merge. Subversion\nrebased your trunk on you, so you...\n\n> I ended up using git cherry-pick, and diff and patch / git diff and git\n> apply.\n\n...wind up needing to do this.\n\nDon't rebase trunk (which implies ditching subversion,\n(un)fortunately), and repeated merges should Just Work. See, for\nexample, the git repository itself, where the master branch is\nrepeatedly merged into next.\n\nPeter Harris\n"},{"id":"99734","messageId":"4966513C.1010707@sneakemail.com","threadId":"16885","inReplyTo":"eaa105840901081029h220e06e4m1a1af693e908751e@mail.gmail.com","subject":"Re: Git (svn) merge - but ignore certain commits?","fromName":"Peter Valdemar Mørch (Lists)","fromEmail":"4ux6as402@sneakemail.com","sentAt":"2009-01-08T19:17:16Z","receivedAt":"2009-01-08T19:17:16Z","isPatch":false,"sender":{"key":"4ux6as402@sneakemail.com","avatar":null},"body":"Peter Harris git-at-peter.is-a-geek.org |Lists| wrote:\n> Well, the real problem is that it *isn't* a repeated merge. Subversion\n> rebased your trunk on you, so you...\n> \n>> I ended up using git cherry-pick, and diff and patch / git diff and git\n>> apply.\n> \n> ...wind up needing to do this.\n> \n> Don't rebase trunk (which implies ditching subversion,\n> (un)fortunately), and repeated merges should Just Work. See, for\n> example, the git repository itself, where the master branch is\n> repeatedly merged into next.\n\nAh, yes. I understand. Thanks for making it more clear to me. There are \ntwo different problems at play here:\n\n1) git svn doesn't help with the fact that svn can't handle the repeated \nmerge problem (just noise here)\n\n2) The git-only repeated-merge problem still exists, if I want a commit \non the branch, but *do not* want it merged back to \"master\". This I \nstill don't see a solution for. E.g.:\n\n---A---B---C---D--+ \"master\"\n     \\--E---F---G-/  \"branch\"\n\nHere I want F and G merged back to \"master\", but *not* E (which is a \nquick-and-dirty but safe version of B). That still seems not to be \npossible. What I did was:\n\n---A---B---C---D--+- \"master\"\n    |             /\n    |\\--F---G----+    \"devbranch\"\n    |             \\\n     \\--E----------+-   \"branch\"\n\n(So F and G got merged from \"devbranch\" to both \"master\" and \"branch\", \nbut E stayed on \"branch\" only)\n\nI could do that because the system worked somewhat without E and I was \nable to develop/test F and G without E. But I'd still be out of luck if \nI needed to work on \"branch\". There seems to me to be no way in the \nfirst two-branch scenario to do repeated merges from \"branch\" to \n\"master\" if I need to avoid that E gets merged back to \"master\".\n\nBut thanks, Peter, for helping me understand. \"git svn\" and the fact \nthat E happened to be a revert where just noise and had nothing to do \nwith the core problem (2). That still has no solution, or am I missing \nsomething?\n\nPeter\n-- \nPeter Valdemar Mørch\nhttp://www.morch.com\n"},{"id":"99739","messageId":"eaa105840901081200i2738dael10e2db35b7cb4750@mail.gmail.com","threadId":"16885","inReplyTo":"4966513C.1010707@sneakemail.com","subject":"Re: Git (svn) merge - but ignore certain commits?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-01-08T20:00:53Z","receivedAt":"2009-01-08T20:00:53Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Thu, Jan 8, 2009 at 2:17 PM, \"Peter Valdemar Mørch (Lists)\" wrote:\n>\n> E.g.:\n>\n> ---A---B---C---D--+ \"master\"\n>    \\--E---F---G-/  \"branch\"\n>\n> Here I want F and G merged back to \"master\", but *not* E (which is a\n> quick-and-dirty but safe version of B).\n\nStop and think about that for a second.\n\nRephrased, \"I want to cherry pick a few commits to master using the\nmerge command\".\n\nThat sounds rather silly when I put it that way. What do you really want? Hmm.\n\nMaybe you want to cherry pick those commits. Maybe (if this is still\nan unpublished branch), you want to \"git rebase --onto B E\" your\nbranch to get the non-dirty version of E, then merge.\n\nOr maybe you do want to merge, but you're getting confused by not\nseeing the automatic conflict markers. You could merge --no-commit the\nbranch, fix the conflicts (E conflicts logically with B, even if 'git\nmerge' doesn't automatically mark it as such -- 'git revert -n E' may\neven do most of the work), and only then commit the merge revision.\nRepeated merges from this state will not keep trying to import E\n(since E is already in the history).\n\nPeter Harris\n"}]}