{"thread":{"id":"5055","subject":"(unsolicited hint) resolving conflicts early","startedAt":"2006-07-31T07:19:00Z","lastAt":"2006-07-31T07:19:00Z","messageCount":1,"participants":["Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"24412","messageId":"7vac6q9r8b.fsf@assigned-by-dhcp.cox.net","threadId":"5055","inReplyTo":null,"subject":"(unsolicited hint) resolving conflicts early","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-31T07:19:00Z","receivedAt":"2006-07-31T07:19:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"In a work flow that employs multiple topic branches, sometimes I\nfind that unrelated topics need to touch the same area of the\ncode, or they do not have textual conflicts but still have\nsemantic interactions.  The topic branch workflow wants you to\nmerge each topic at least twice (once while testing and another\ntime when you declare topic to be ready), which means you would\nneed to resolve the same conflict at least twice.\n\nHere is a trick I've been using to deal with such a case.\n\nA quick refresher course of \"topic branch\" workflow:\n\n - you branch off from your primary branch (typically \"master\")\n   and create one branch per development topic.\n\n - your development takes place on the topic branches.\n\n - each topic can (and should) be tested alone, but you would\n   want to test them as a whole in order to make sure your\n   topics mesh together well.  Typically you use a branch other\n   than your primary branch to merge them all and use the result\n   for testing.  Depending on your taste, this test branch could\n   be throw-away, or long lived (e.g. my \"pu\" is throw-away, as\n   opposed to \"next\" which is a long-lived test branch).\n\n - When a topic becomes fully cooked, you merge it into your\n   primary branch.\n\nWhen two logically independent topics need to touch the same\narea of code, or have semantic interactions that do not\nnecessarily involve textual merge conflicts, they need to be\nresolved when the topics are merged into the test branch.\n\nYou would not know which topic becomes ready to be merged to\nyour primary branch first, but eventually you would want to have\nboth of them graduate to your mainline.  So when you merge the\nsecond topic into your mainline, you would need to resolve the\nsame conflict you resolved when you merged it to the test branch.\n\nHowever, it is not easy to \"reuse\" the merge resolution.  rerere\nhelps you reuse textual conflict resolution, but fixups needed\nthat do not involve textual conflicts are not handled by\n\"rerere\".\n\nFor example, I have \"lt/setup\" that restructures calls to\nsetup_git_directory(), and \"js/mv\" that introduces a new\nbuilt-in implementation of \"git mv\".  They both touch the\ncommand table in git.c which causes textual conflicts, and the\nformer changes the calling convention of all built-in command\nimplementations, so builtin-mv.c::cmd_mv() (which does not have\nany textual conflict) needs to be modified when these two\nbranches are used together.\n\nThe way I solve this is to use the third branch (\"conflict\nresolution branch between the two topic branches\").  You branch\nthis off of one of the topic branches and merge in the other,\nand resolve conflicts there.  For example, I have __/setup-n-mv\nbranch which merges lt/setup and js/mv, and that branch is what\nis merged into \"next\" (the test branch):\n\n\t$ git checkout -b __/setup-n-mv lt/setup\n        $ git pull . js/mv\n        ... fix textual merge conflicts here.\n\t... compile testing reveals that further fixups are needed;\n\t... fix them up here as well.\n\t... this can become an \"evil merge\", or a separate\n        ... \"fixup\" commit can be made in this resolution branch.\n\t$ git commit -a\n\t$ git checkout next ; git pull . __/setup-n-mv\n\nWhen one of the branches is ready to be merged to \"master\", I\ncan just do so.  After that, I merge the conflict resolution\nbranch into the other topic.    This way, when the other one\ngraduates, the merge conflict is already resolved and the\nmerging into \"master\" becomes quite easy.\n\nA good thing here is that it is a lot easier to see what\ninteractions the topics have while merging them to \"next\" for\ntesting than later merging the first and then sometime later\nmerging the second topic to \"master\", because the former happens\nsoon after I take patches to the topic branch (or I work on the\ntopic myself).  Merging the second branch to \"master\" happens\nmuch later, at which point I may need to do extra work to\nremember the details of what interactions the topics had and\nwhat were needed to resolve them (not just textually but\nsemantically).\n\nHTH ;-).\n"}]}