{"thread":{"id":"18051","subject":"proper way to merge?","startedAt":"2009-02-27T22:11:22Z","lastAt":"2009-03-03T16:15:29Z","messageCount":9,"participants":["John Dlugosz","John Tapsell","Bryan Donlan","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"106485","messageId":"450196A1AAAE4B42A00A8B27A59278E709F06FDA@EXCHANGE.trad.tradestation.com","threadId":"18051","inReplyTo":null,"subject":"proper way to merge?","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-02-27T22:11:22Z","receivedAt":"2009-02-27T22:11:22Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"I'm merging two branches: let's say \"dev\" is for development of future\nreleases, and \"rel\" is changes made to the current release for immediate\napplication. Now I want to bring the changes made in rel back to dev.\n\nRather than trying to merge it all at once, I'm applying the changes a\nfew at a time and making sure it still compiles as I go. Then,\ngit-reset and I have dev as my HEAD and the desired merge result in the\nworking tree.\n\nNow, I want to introduce the proper commit node to show that this is the\ngraft. But, I don't want to be presented with all the differences that\nI already resolved; I know what it should look like already. How do I\ncommit the current state of things and have it show up with both dev and\nrel as parents? (then make that the new dev)\n\nI'm also interesting in learning how to do it better next time. But I'm\ndoing the incremental merging now and need to know how to conclude it.\n\n--John\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.\n If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"106516","messageId":"43d8ce650902272358h4219f439qfa60ba7a7e0d222f@mail.gmail.com","threadId":"18051","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E709F06FDA@EXCHANGE.trad.tradestation.com","subject":"Re: proper way to merge?","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-02-28T07:58:14Z","receivedAt":"2009-02-28T07:58:14Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/2/27 John Dlugosz :\n> I'm merging two branches: let's say \"dev\" is for development of future\n> releases, and \"rel\" is changes made to the current release for immediate\n> application.  Now I want to bring the changes made in rel back to dev.\n>\n> Rather than trying to merge it all at once, I'm applying the changes a\n> few at a time and making sure it still compiles as I go.  Then,\n> git-reset and I have dev as my HEAD and the desired merge result in the\n> working tree.\n>\n> Now, I want to introduce the proper commit node to show that this is the\n> graft.  But, I don't want to be presented with all the differences that\n> I already resolved; I know what it should look like already.  How do I\n> commit the current state of things and have it show up with both dev and\n> rel as parents? (then make that the new dev)\n>\n> I'm also interesting in learning how to do it better next time.  But I'm\n> doing the incremental merging now and need to know how to conclude it.\n\nInstead of merge, I prefer to rebase. so:\n\ngit checkout dev\ngit rebase origin rel\n\nThis replays each commit made in 'dev' on top of release, letting you\nfix each commit separately. It also means that when I commit to\nrelease, the changes are a nice tree.\n\nThis only works if you have a relatively small number of changes. I\ntried to rebase 50 patches from 'dev' to 'rel' where the patches\nchanged pretty much every file. It took all day to do. (But it was\nstill better than trying to merge, in my specific case)\n\nJohnFlux\n\n\n\n>\n> --John\n>\n> TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"106680","messageId":"3e8340490903020033l78329c82la186cadaa528bc32@mail.gmail.com","threadId":"18051","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E709F06FDA@EXCHANGE.trad.tradestation.com","subject":"Re: proper way to merge?","fromName":"Bryan Donlan","fromEmail":"bdonlan@gmail.com","sentAt":"2009-03-02T08:33:59Z","receivedAt":"2009-03-02T08:33:59Z","isPatch":false,"sender":{"key":"bdonlan@gmail.com","avatar":null},"body":"On Fri, Feb 27, 2009 at 5:11 PM, John Dlugosz wrote:\n> I'm merging two branches: let's say \"dev\" is for development of future\n> releases, and \"rel\" is changes made to the current release for immediate\n> application.  Now I want to bring the changes made in rel back to dev.\n>\n> Rather than trying to merge it all at once, I'm applying the changes a\n> few at a time and making sure it still compiles as I go.  Then,\n> git-reset and I have dev as my HEAD and the desired merge result in the\n> working tree.\n>\n> Now, I want to introduce the proper commit node to show that this is the\n> graft.  But, I don't want to be presented with all the differences that\n> I already resolved; I know what it should look like already.  How do I\n> commit the current state of things and have it show up with both dev and\n> rel as parents? (then make that the new dev)\n>\n> I'm also interesting in learning how to do it better next time.  But I'm\n> doing the incremental merging now and need to know how to conclude it.\n\nSo, if I understand correctly, you've manually applied (manually\napplying diffs or something?) your changes from the release branch to\nthe dev branch, and now want to inform git of what happened?\n\nIf so, you could commit what you have now, use a graft to change its\nparentage, then git-filter-branch to actually update the commit\nobject. Something like this, I believe:\ngit commit -m 'Merge .....'\necho ' ' >> .git/info/grafts\ngit-filter-branch dev~..dev\n## You can remove (that line from) .git/info/grafts now\n\nIn the future, you may want to perform this sort of incremental merge\nby simply git merging intermediate revisions in the release branch.\n"},{"id":"106731","messageId":"450196A1AAAE4B42A00A8B27A59278E709F07432@EXCHANGE.trad.tradestation.com","threadId":"18051","inReplyTo":"43d8ce650902272358h4219f439qfa60ba7a7e0d222f@mail.gmail.com","subject":"RE: proper way to merge?","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-02T22:19:38Z","receivedAt":"2009-03-02T22:19:38Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"===Re:===\nInstead of merge, I prefer to rebase. so:\n\ngit checkout dev\ngit rebase origin rel\n\nThis replays each commit made in 'dev' on top of release, letting you\nfix each commit separately. It also means that when I commit to\nrelease, the changes are a nice tree.\n===end===\n\nThe reason I'm doing this -- why I took over maintenance of the repository -- is because I strenuously objected to his plan to \"rebase\". NO! Merge, don't rebase. Besides never rebasing published branches, in this case it works much better the other way around: dev made systemic changes, and rel is mostly patches and completely new pieces of code. After looking at what was in dev..rel and what was in rel..dev, I chose to start with dev and bring in the commits from rel in a controlled manner.\n\nI think you are indicated that the rebase is easier because the merge is done one commit at a time rather than in one huge bang. I want to have that advantage and then some by picking related groups of commits and verifying that it still compiles before getting more, not even limited to the original order.\n\nI'll post what I learned in a separate note.\n\n--John\n(excuse the footer; it's not my choice)\n\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"106734","messageId":"450196A1AAAE4B42A00A8B27A59278E709F07452@EXCHANGE.trad.tradestation.com","threadId":"18051","inReplyTo":"3e8340490903020033l78329c82la186cadaa528bc32@mail.gmail.com","subject":"RE: proper way to merge?","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-02T22:44:12Z","receivedAt":"2009-03-02T22:44:12Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"===Re:===\nSo, if I understand correctly, you've manually applied (manually\napplying diffs or something?) your changes from the release branch to\nthe dev branch, and now want to inform git of what happened?\n\nIf so, you could commit what you have now, use a graft to change its\nparentage, then git-filter-branch to actually update the commit\nobject. Something like this, I believe:\ngit commit -m 'Merge .....'\necho ' ' >> .git/info/grafts\ngit-filter-branch dev~..dev\n## You can remove (that line from) .git/info/grafts now\n\nIn the future, you may want to perform this sort of incremental merge\nby simply git merging intermediate revisions in the release branch.\n===end===\n\nThat's very interesting. I did not find 'grafts' in the documentation,\nbut I looked for it now that I know about it. So you can add another\nparent to the graph just by adding a line to that file. BTW,\nfilter-branch isn't available on msysgit. But leaving it in that grafts\nfile should be OK -- is that pushed/pulled with everything else?\n\n--John\n\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.\n If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"106758","messageId":"43d8ce650903022101x584d7dcfr1758efc5e2c2e5cc@mail.gmail.com","threadId":"18051","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E709F07432@EXCHANGE.trad.tradestation.com","subject":"Re: proper way to merge?","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-03-03T05:01:30Z","receivedAt":"2009-03-03T05:01:30Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/3/2 John Dlugosz :\n> ===Re:===\n> Instead of merge, I prefer to rebase.  so:\n>\n> git checkout dev\n> git rebase origin rel\n>\n> This replays each commit made in 'dev' on top of release, letting you\n> fix each commit separately.  It also means that when I commit to\n> release, the changes are a nice tree.\n> ===end===\n>\n> The reason I'm doing this -- why I took over maintenance of the repository -- is because I strenuously objected to his plan to \"rebase\".  NO!  Merge, don't rebase.  Besides never rebasing published branches, in this case it works much better the other way around:  dev made systemic changes, and rel is mostly patches and completely new pieces of code.  After looking at what was in dev..rel and what was in rel..dev, I chose to start with dev and bring in the commits from rel in a controlled manner.\n\nIt depends on what you're doing :-) I find that if the branch is too\nlarge to easily rebase, then it's probably too large entirely :)\nDevelopers don't like master to change in large ways suddenly - makes\nit hard for all the other branches.\n\nIt also makes it impossible to bisect, something that I find\nessential. If you are combining two trees which are too big to easily\nrebase, then there's a high chance that something will break either\ndue to their individual changes or because of a mistake while merging.\n In such a case, it's then impossible to bisect to try to pinpoint the\nactual problem.\n\nIt will be interesting to hear your view on merging vs rebasing after\na year or so of trying both.\n\nJohn\n"},{"id":"106775","messageId":"49ACDD17.2060601@viscovery.net","threadId":"18051","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E709F07452@EXCHANGE.trad.tradestation.com","subject":"Re: proper way to merge?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-03-03T07:32:39Z","receivedAt":"2009-03-03T07:32:39Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"John Dlugosz schrieb:\n> I did not find 'grafts' in the documentation,\n> but I looked for it now that I know about it. So you can add another\n> parent to the graph just by adding a line to that file. BTW,\n> filter-branch isn't available on msysgit.\n\nHuh? filter-branch *is* in msysgit. Why do you think it is not?\n\n> But leaving it in that grafts\n> file should be OK -- is that pushed/pulled with everything else?\n\nNo.\n\nYou really want to use filter-branch if the new parent is to be permanent.\n\n-- Hannes\n"},{"id":"106862","messageId":"450196A1AAAE4B42A00A8B27A59278E709F075F9@EXCHANGE.trad.tradestation.com","threadId":"18051","inReplyTo":"49ACDD17.2060601@viscovery.net","subject":"RE: proper way to merge?","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-03T16:04:03Z","receivedAt":"2009-03-03T16:04:03Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"===Re:===\nHuh? filter-branch *is* in msysgit. Why do you think it is not?\n===end===\n\nBecause when I tried it I got \" git: 'filter-branch' is not a\ngit-command. See 'git --help'.\"\nThen I looked in the Git installation directory and did not find any\nfile with that name. Then I looked at the ReleaseNotes.rtf file in the\ntop of the Git installation tree and saw, \n\" *\tSome commands are not yet supported on Windows and excluded from\nthe installation; namely: git archimport, git cvsexportcommit, git\ncvsimport, git cvsserver, git filter-branch, git instaweb, git\nsend-email, git shell, git svn.\"\n\n\nSo I wonder why you think it *is* in msysgit? This is the latest\nversion from their site.\n\n--John\n(please excuse the footer; it's not my idea)\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.\n If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"106866","messageId":"49AD57A1.9080109@viscovery.net","threadId":"18051","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E709F075F9@EXCHANGE.trad.tradestation.com","subject":"Re: proper way to merge?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-03-03T16:15:29Z","receivedAt":"2009-03-03T16:15:29Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"John Dlugosz schrieb:\n> \" *\tSome commands are not yet supported on Windows and excluded from\n> the installation; namely: git archimport, git cvsexportcommit, git\n> cvsimport, git cvsserver, git filter-branch, git instaweb, git\n> send-email, git shell, git svn.\"\n\nA-ha. If there ever was a reason to exclude filter-branch, then I think\nthis reason is no more.\n\n> So I wonder why you think it *is* in msysgit? This is the latest\n> version from their site.\n\nBecause I don't use the msysgit installer, but compile git myself. I have\na working filter-branch.\n\n-- Hannes\n"}]}