{"thread":{"id":"5366","subject":"Proposal for new git Merge Strategy","startedAt":"2006-08-23T18:40:39Z","lastAt":"2006-08-23T23:05:53Z","messageCount":4,"participants":["Jon Loeliger","Jakub Narebski","Junio C Hamano","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"25812","messageId":"E1GFxeZ-0000Nw-ED@jdl.com","threadId":"5366","inReplyTo":null,"subject":"Proposal for new git Merge Strategy","fromName":"Jon Loeliger","fromEmail":"jdl@jdl.com","sentAt":"2006-08-23T18:40:39Z","receivedAt":"2006-08-23T18:40:39Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"Folks,\n\nThe other day, I was talking to some other folks else-list\nabout git's approach to merges and mentioned that there was\nsome structure in place to handle different merge strategies.\n\nOne person observed that Perforce had a really good\napproach to merging and conflict resolution that allowed\nuser interaction during the process specifically to\nhelp select the individual files and hunks that contributed\nto the final result.  I confess that I have never used\nPerforce, so this is all hear-say and interpretation. :-)\n\nHowever, it does seem like an approach that we could\neasily add to git -- not as the default of course.\n(Just think how dead we'd all be if Linus had to manually\ninteract with every merge he performed at the tip of the\nLinux Pyramid. :-)\n\nBut for complex or critical merges, a \"guided merge\"\nstrategy seems like it might be a useful tool.  Basically,\nit would offer options to select Stage 1 or Stage 2\nrevisions, or step in and offer hunks from Stage 1 and 2,\nrevert to \"ours\" or \"theirs\", or \"revert to 'ours' or 'theirs'\nfor all remaining files\".  Things like that maybe.\n\nAny thoughts down this line?  Good idea?  Bad idea?\n\nThanks,\njdl\n\nPS -- Please keep mwm on the CC: list as he doesn't\n      directly subscribe to the git list, but would\n      like to participate in the thread.  Thanks!\n"},{"id":"25814","messageId":"eci8nh$uk3$1@sea.gmane.org","threadId":"5366","inReplyTo":"E1GFxeZ-0000Nw-ED@jdl.com","subject":"Re: Proposal for new git Merge Strategy","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-23T19:02:09Z","receivedAt":"2006-08-23T19:02:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Loeliger wrote:\n\n> The other day, I was talking to some other folks else-list\n> about git's approach to merges and mentioned that there was\n> some structure in place to handle different merge strategies.\n> \n> One person observed that Perforce had a really good\n> approach to merging and conflict resolution that allowed\n> user interaction during the process specifically to\n> help select the individual files and hunks that contributed\n> to the final result.  I confess that I have never used\n> Perforce, so this is all hear-say and interpretation. :-)\n> \n> However, it does seem like an approach that we could\n> easily add to git -- not as the default of course.\n> (Just think how dead we'd all be if Linus had to manually\n> interact with every merge he performed at the tip of the\n> Linux Pyramid. :-)\n> \n> But for complex or critical merges, a \"guided merge\"\n> strategy seems like it might be a useful tool.  Basically,\n> it would offer options to select Stage 1 or Stage 2\n> revisions, or step in and offer hunks from Stage 1 and 2,\n> revert to \"ours\" or \"theirs\", or \"revert to 'ours' or 'theirs'\n> for all remaining files\".  Things like that maybe.\n\nAnd select which files are which (after renaming, copying, etc.)\n\n> Any thoughts down this line?  Good idea?  Bad idea?\n\nWouldn't it be better to fallback to graphical/user guided \nmerger only on _failed_ merge? Merge helpers like xxdiff, \nMeld or KDiff3 \n  http://git.or.cz/gitwiki/InterfacesFrontendsAndToolsWishlist\nThere was proposal of git script which run xxdiff with correct\nextracted files, if I remeber correctly postponed waiting for\nmore generic version.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25816","messageId":"7vsljngr34.fsf@assigned-by-dhcp.cox.net","threadId":"5366","inReplyTo":"E1GFxeZ-0000Nw-ED@jdl.com","subject":"Re: Proposal for new git Merge Strategy","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-23T20:00:31Z","receivedAt":"2006-08-23T20:00:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@jdl.com> writes:\n\n> But for complex or critical merges, a \"guided merge\"\n> strategy seems like it might be a useful tool.  Basically,\n> it would offer options to select Stage 1 or Stage 2\n> revisions, or step in and offer hunks from Stage 1 and 2,\n> revert to \"ours\" or \"theirs\", or \"revert to 'ours' or 'theirs'\n> for all remaining files\".  Things like that maybe.\n>\n> Any thoughts down this line?  Good idea?  Bad idea?\n\nWe had some discussion on this with Catalin in \"Unresolved\nissues #3\" thread, regarding git-xxdiff (did I ever take it?  I\nliked it for what it does, but I was not sure about its\nodd-man-out-ness) which was proposed by Martin Langhoff.\n\nA merge that results in manual fixups conceptually take these\nsteps:\n\n - revs involved in 3-way merge identified with git-merge-base;\n\n - read-tree is given these three bases;\n\n - git-merge-index gives three stages as individual temporary\n   files to git-merge-one-file for each path that cannot be\n   resolved at tree-level.\n\n   - git-merge-one-file calls \"merge\" (reminds me that I should\n     replace this with \"diff3\").\n\nWe should be able to make the part that call \"merge/diff3\" to\nalternatively call xxdiff or its friends (kompare, emerge, pick\nyour favorites).  Catalin even showed us a code snippet used in\nStGIT for this in the thread.\n\nMartin's proposed tool git-xxdiff is meant to be invoked after\nall of the above still left conflict markers.  As Catalin\npointed out, using \"xxdiff -U\" to work on a file with conflict\nmarkers is less powerful than working on three stages directly,\nbut on the other hand it can be used as the last stage fixup,\nindependent from what git-merge does internally.  In other\nwords, it is meant to help solving the same problem but in a\ndifferent part of the workflow.\n"},{"id":"25822","messageId":"46a038f90608231605w4d08d59bw42fc84669e16363f@mail.gmail.com","threadId":"5366","inReplyTo":"7vsljngr34.fsf@assigned-by-dhcp.cox.net","subject":"Re: Proposal for new git Merge Strategy","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-08-23T23:05:53Z","receivedAt":"2006-08-23T23:05:53Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/24/06, Junio C Hamano <junkio@cox.net> wrote:\n> Jon Loeliger <jdl@jdl.com> writes:\n...\n> > Any thoughts down this line?  Good idea?  Bad idea?\n>\n> We had some discussion on this with Catalin in \"Unresolved\n> issues #3\" thread, regarding git-xxdiff (did I ever take it?  I\n> liked it for what it does, but I was not sure about its\n> odd-man-out-ness) which was proposed by Martin Langhoff.\n\nI've been slack on my reading of the list lately so totally missed out\non that thread. I'll go and read it now...\n\n...\n\n> We should be able to make the part that call \"merge/diff3\" to\n> alternatively call xxdiff or its friends (kompare, emerge, pick\n> your favorites).  Catalin even showed us a code snippet used in\n> StGIT for this in the thread.\n\nI still think that the default initial behaviour git has is right.\nMost conflicts are trivial, and people can deal with conflict markers\njust right. It's what we are used to.\n\nExcept when it's a mess and it's unclear what goes where and why.\nThat's when git log --merge and my git-xxdiff help. I've also been\nwondering if I can do gitk --merge easily ;-)\n\n> Martin's proposed tool git-xxdiff is meant to be invoked after\n> all of the above still left conflict markers.  As Catalin\n> pointed out, using \"xxdiff -U\" to work on a file with conflict\n> markers is less powerful than working on three stages directly,\n> but on the other hand it can be used as the last stage fixup,\n> independent from what git-merge does internally.  In other\n> words, it is meant to help solving the same problem but in a\n> different part of the workflow.\n\nMy implementation doesn't use the 3 stages either, just because I\ndidn't see xxdiff giving any stage a particular meaning. I should\nrework it to have the 3 stages there, and trust users to read the\nfilename, which should say 'ancestor'.\n\nIn terms of the one script or many, if there is concensus on\nOneScriptToRuleThemAll, I am not that opposed to reworking it to\nsomething like\n\n  git-mergehelper --tool xxdiff path/to/file.c\n\nwith a big switch statement inside the script :-p What bothers me is\nthat there may be interesting parameters to pass to the invoked tool,\nand other than having a stupid '--toolopts' passthrough, we are pretty\nfsck'd.\n\nBy having separate git-xxdiff, git-meld, etc the git- scripts would\naccept all/most of the same params that the tool accepts, therefore\nfeeling \"natural\" to users of the tool. A definite advantage, IMHO.\n\n{Ugh, my implementation doesn't get that far. But hey, good intentions!}\n\ncheers,\n\n\n\nmartin\n"}]}