{"thread":{"id":"1917","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","startedAt":"2005-09-22T19:12:45Z","lastAt":"2005-09-23T09:01:15Z","messageCount":7,"participants":["Jon Loeliger","Linus Torvalds","Daniel Barkalow","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"9131","messageId":"E1EIWUv-0004HR-F6@jdl.com","threadId":"1917","inReplyTo":null,"subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-09-22T19:12:45Z","receivedAt":"2005-09-22T19:12:45Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"\nLinus calmly explained again:\n>\n> The \"origin\" branch was already updated automatically if you used\n> \n> \tgit pull origin\n> \n> However, if you used\n> \n> \tgit pull rsync:..../linus-2.6.git\n> \n> then git would only have fetched the objects, and _not_ updated the \n> \"origin\" branch (because you didn't tell it about the \"origin\" branch). \n> \n> But you can trivially fix that by doing\n> \n> \tgit fetch origin\n> \n> at this point, which will end up doing the equivalent of\n> \n> \tgit fetch rsync:..../linus-2.6.git master:origin\n> \n> (depending on what the contents of your .git/remotes/origin are, of \n> course, the above is just an example).\n\nThis was a very helpful section for me.\n\n> For example, it _may_ just contain something like\n> \n>\tURL: rsync:..../linus2.6.git\n> \n> in which case there is no explicit heads specified. In that case, you \n> really should specify _which_ of the heads you want to pull, and what the \n> target should be. \n\nIn fact it contained just the \"rsync:....\" bits.\n\n\n> For example, you can do that with\n>\n>\tgit fetch linus master:linus\n>\n> which says: \"fetch the branch 'master' from the repository described by \n> 'linus' (.git/remotes/linus) into _my_ branch 'linus'\".\n\nJust to be clear on the overloaded use of \"linus\" here,\nlet me rewrite that:\n\n\tgit fetch foo master:bar\n\n    which says: \"fetch the branch 'master' from the repository described\n    by 'foo' (.git/remotes/foo) into _my_ branch 'bar'\".\n\nRight?\n\n> Now, you can specify that this is what you _always_ want to do, and\n> actually set the branches in the \".git/remotes/linus\" file explicitly.\n> You can make your .git/remotes/linus file look like this instead:\n>\n>\tURL: rsync:..../linus2.6.git\n>\tPull: master:linus\n\nOK.  I think I get it.  The concept you are trying to beat into\nmy head is essentially the difference between a \"complete\" and\nan \"incomplete\" specifier.  If there is enough specification to\nfetch and merge into a branch, you can.  And there are a few\ndifferent ways to do so:\n\n    A) git fetch rsync:..../linus-2.6.git master:origin\nor \n    B) git fetch linus master:linus\n       with just the URL bits in the .git/remotes\nor\n    C)\tgit fetch linus\n        with both URL and \"Pull:\" clauses in .git remotes\n            URL: rsync:..../linus2.6.git\n\t    Pull: master:linus\n\nIf it is an incomplete specification (without branch names),\nyou just can't do the whole sheebang.  You have to stop after\nfetching the objects.\n\nAnd add \"merging\" in the \"git pull\" cases.\n\n> Now, this is where \"dirty\" comes in. The merge will fail if you have \n> changed any files that the merge wants to modify. So do a\n\nD'oh.  This is what bites me.  Some of those diffs that\ncome back to me in the linus tree are one that I originated\nand sent up stream in the first place.  To get those to\nwash-out with the merge, I will have had to have had those\ncommitted in my branch, right?  Otherwise they just look\nlike dirty files -- never mind that they are (should be)\nthe exact same bits coming back at me.\n\n> So do a\n>\n>\tgit diff --name-only HEAD\n>\n> to see if there are any changes, and commit them - or undo them - if so.\n> Then try to pull again.\n\nAh hah.  OK.\n\n\nI want to return to this for one last comment:\n\n    > You can make your .git/remotes/linus file look like this instead:\n    >\n    >\tURL: rsync:..../linus2.6.git\n    >\tPull: master:linus\n\nSo, philosophically perhaps, there are several different\nreasons for having branches within a repository.  One of\nthem is to track external repositories as indicated above.\nBut no-one (ie, no tool) currently constructs the .git/remotes\nfiles to have that layout, right?  I mean, The One True editor\ncan, but there is no git or Cogito command that says to\nconstruct the URL: and Pull: bits like that for the purposes\nof establishing a \"track branch\", right?  Would it make sense\nto have a \"--tracking\" flag added to branch creation that\ntrumped these bits up and promotes a simpler, or specific\npurpose branch?\n\njdl\n"},{"id":"9136","messageId":"Pine.LNX.4.58.0509221413400.2553@g5.osdl.org","threadId":"1917","inReplyTo":"E1EIWUv-0004HR-F6@jdl.com","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-22T21:22:08Z","receivedAt":"2005-09-22T21:22:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 22 Sep 2005, Jon Loeliger wrote:\n>\n> > For example, you can do that with\n> >\n> >\tgit fetch linus master:linus\n> >\n> > which says: \"fetch the branch 'master' from the repository described by \n> > 'linus' (.git/remotes/linus) into _my_ branch 'linus'\".\n> \n> Just to be clear on the overloaded use of \"linus\" here,\n> let me rewrite that:\n> \n> \tgit fetch foo master:bar\n> \n>     which says: \"fetch the branch 'master' from the repository described\n>     by 'foo' (.git/remotes/foo) into _my_ branch 'bar'\".\n> \n> Right?\n\nRight.\n\n> OK.  I think I get it.  The concept you are trying to beat into\n> my head is essentially the difference between a \"complete\" and\n> an \"incomplete\" specifier.  If there is enough specification to\n> fetch and merge into a branch, you can.  And there are a few\n> different ways to do so:\n> \n>     A) git fetch rsync:..../linus-2.6.git master:origin\n> or \n>     B) git fetch linus master:linus\n>        with just the URL bits in the .git/remotes\n> or\n>     C)\tgit fetch linus\n>         with both URL and \"Pull:\" clauses in .git remotes\n>             URL: rsync:..../linus2.6.git\n> \t    Pull: master:linus\n\nAbsolutely.\n\nNote that you can also override, so let's say that you have _both_ the\n\"URL:\" and the \"Pull:\" line in your \"remotes\" file, the \"pull\" line is \nstill just a default, so you could do\n\n\tgit fetch linus other:myother\n\nand it would now use the URL line, but since you specified the branch by\nhand, it would ignore the default branch information, and instead fetch\nthe \"other\" branch from the remote site into the \"myother\" local branch.\n\n> > Now, this is where \"dirty\" comes in. The merge will fail if you have \n> > changed any files that the merge wants to modify. So do a\n> \n> D'oh.  This is what bites me.  Some of those diffs that\n> come back to me in the linus tree are one that I originated\n> and sent up stream in the first place.  To get those to\n> wash-out with the merge, I will have had to have had those\n> committed in my branch, right?\n\nYes. Then git will merge them for you automatically (if they are \nidentical), or may ask you to fix up any merge rejects (if there are \nclashes). \n\nNow, the fixing up any merges is pretty much exactly the same as under \nCVS - you'll get the same \"<<<<\" \"====\" \">>>>\" markers.\n\n>\t\t\t  Otherwise they just look\n> like dirty files -- never mind that they are (should be)\n> the exact same bits coming back at me.\n\nRight, but git doesn't know, and is too lazy to check. \n\nI _considered_ allowing a dirty file that happened to match the end \nresult, but I never felt it was worth the complexity. It's nasty. And if \nit doesn't match, you really can't merge, because it's too dangerous to \noverwrite the users changes (even if you use some three-way merge and \nleave the rejects there).\n\n> I want to return to this for one last comment:\n> \n>     > You can make your .git/remotes/linus file look like this instead:\n>     >\n>     >\tURL: rsync:..../linus2.6.git\n>     >\tPull: master:linus\n> \n> So, philosophically perhaps, there are several different\n> reasons for having branches within a repository.  One of\n> them is to track external repositories as indicated above.\n\nYes.\n\n> But no-one (ie, no tool) currently constructs the .git/remotes\n> files to have that layout, right?\n\nThe \"git clone\" thing will construct the original \"origin\" file to that \nlayout. That's fairly recent, though.\n\nAnd I think \"cg-branch\" will do it these days - and that's very much the\nintent.  Havign porcelain on top of git that hides this thing so that you\ndon't have to edit configuration files by hand.\n\n(Don't get me wrong: I think it's wonderful to have ASCII configuration \nfiles that you _can_ edit by hand, and it's the UNIX way of doing things, \nbut I also think it's great to have front-end tools that allow doing these \nthings without even having to understand the config file syntax etc).\n\n\t\tLinus\n"},{"id":"9138","messageId":"Pine.LNX.4.58.0509221427520.2553@g5.osdl.org","threadId":"1917","inReplyTo":"Pine.LNX.4.58.0509221413400.2553@g5.osdl.org","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-22T21:37:43Z","receivedAt":"2005-09-22T21:37:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 22 Sep 2005, Linus Torvalds wrote:\n> \n> Now, the fixing up any merges is pretty much exactly the same as under \n> CVS - you'll get the same \"<<<<\" \"====\" \">>>>\" markers.\n\nI should have continued this. \n\nWhat you do is you just edit the end result to be what it should be \n(exactly as under CVS), and then you do \"git commit --all\" to commit the \nmanual merge.\n\nNOTE NOTE NOTE! This is one case where if you had dirty state in your tree\nbefore the merge, that you need to be careful. In that case you obviously\nmust NOT use \"--all\", since that will commit all the dirty state - both\nyour old dirty state _and_ your manual merge resolve. So if you had other \nchanges in your tree that you don't want to commit, you need to do\n\n\tgit commit <list manually merged files individually here>\n\nso that it doesn't commit anything else. \n\nOh. And while preparing the merge, you can use\n\n\tgit diff\n\nto see what the manual part was: the automated part of the merge will have\nupdated index for the automatic side, so this will _not_ show the part \nof the merge that was done automatically for you.\n\nOr, of you want to see _everything_ the merge has done, just do\n\n\tgit diff HEAD\n\nto see what the _total_ diff from your pre-merge head was to what is now\nin your tree. But that will be the diff for what you're merging - so it\ncan be _huge_ if you're pulling my tree and merging everything I've\naccepted over the last week or two.\n\nAnd if the merge ends up being too complex, and you decide that you need \nhelp and want to undo the partial merge entirely and not even try to fix \nit up, do\n\n\tgit reset --hard\n\nwhich will roll back the index and the working tree to your old HEAD (BUT \nLOOK OUT! IT WILL ALSO DESTROY ANY DIRTY STATE YOU HAD BEFORE THE MERGE!).\n\nBasically: having dirty state in your tree and then ending up having to do \na manual merge is a big pain. Not worth it. I just keep really small dirty \nstuff so that I don't mind blowing it away if I need to.\n\n\t\tLinus\n"},{"id":"9140","messageId":"Pine.LNX.4.63.0509221747340.23242@iabervon.org","threadId":"1917","inReplyTo":"Pine.LNX.4.58.0509221427520.2553@g5.osdl.org","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-22T21:57:36Z","receivedAt":"2005-09-22T21:57:36Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 22 Sep 2005, Linus Torvalds wrote:\n\n> Basically: having dirty state in your tree and then ending up having to do \n> a manual merge is a big pain. Not worth it. I just keep really small dirty \n> stuff so that I don't mind blowing it away if I need to.\n\nWould it be worthwhile to have a flag to make git-read-tree abort rather \nthan making a mess if you have any dirty state and the merge isn't \ncompletely automatic? It's certainly easy enough to write.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"9142","messageId":"Pine.LNX.4.58.0509221500150.2553@g5.osdl.org","threadId":"1917","inReplyTo":"Pine.LNX.4.63.0509221747340.23242@iabervon.org","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-22T22:05:02Z","receivedAt":"2005-09-22T22:05:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 22 Sep 2005, Daniel Barkalow wrote:\n> \n> Would it be worthwhile to have a flag to make git-read-tree abort rather \n> than making a mess if you have any dirty state and the merge isn't \n> completely automatic? It's certainly easy enough to write.\n\nI don't think it would be wrong, necessarily.\n\nOn the other hand, it might be easier to just instead do a \n\n\tgit diff HEAD > .git/pre-merge-diff\n\nand let it go at that. If the merge ends up being nasty, you can then just \ndo\n\n\tgit reset --hard\n\tgit-apply .git/pre-merge-diff\n\nor something.\n\nI dunno. This is not something that has caused me a lot of headache. I \ncertainly _hope_ that people generally don't keep a lot of dirty state \naround: I do it for truly small stuff that I don't care about.\n\nLet's face it - if I cared about it, I'd have committed it (possibly to\nanother branch). It's not like that's hard. So the dirty stuff really does \ntend to be only trivial things.\n\n\t\tLinus\n"},{"id":"9156","messageId":"7vslvwfajf.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1917","inReplyTo":"Pine.LNX.4.58.0509221500150.2553@g5.osdl.org","subject":"[PATCH] Fix overzealous cleanliness check in git-merge","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-23T08:33:40Z","receivedAt":"2005-09-23T08:33:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Being able to try multiple strategies and automatically picking one\nthat seems to give less conflicting result may or may not much sense\nin practice.  At least that should not force normal use case to\nadditionally require the working tree to be fully clean.  As Linus\nshouted, local changes do not matter unless they interfere with the\nmerge.\n\nThis commit changes git-merge not to require a clean working tree.\nOnly when we will iterate through more than one merge strategies,\nlocal changes are stashed away before trying the first merge, and\nrestored before second and later merges are attempted.\n\nThe index file must be in sync with HEAD in any case -- otherwise the\nmerge result would contain changes since HEAD that was done locally\nand registered in the index.  This check is already enforced by\nthree-way read-tree existing merge strategies use, but is done here as\na safeguard as well.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n Taking hint from your message, here is an attempt to fix the\n 'incredibly broken' git-merge.  This does not make git-pull\n use it yet.\n\n git-merge.sh |   65 ++++++++++++++++++++++++++++++++++++++++++++--------------\n 1 files changed, 49 insertions(+), 16 deletions(-)\n\nabfefa19cf56a312d571ea36a491152ac7aef657\ndiff --git a/git-merge.sh b/git-merge.sh\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -18,8 +18,19 @@ all_strategies='recursive octopus resolv\n default_strategies='resolve octopus'\n use_strategies=\n \n-dropheads() {\n-\trm -f -- \"$GIT_DIR/MERGE_HEAD\" || exit 1\n+dropsave() {\n+\trm -f -- \"$GIT_DIR/MERGE_HEAD\" \\\n+\t\t \"$GIT_DIR/MERGE_SAVE\" || exit 1\n+}\n+\n+savestate() {\n+\tgit diff -r -z --name-only $head | cpio -0 -o >\"$GIR_DIR/MERGE_SAVE\"\n+}\n+\n+restorestate() {\n+\tgit reset --hard $head\n+\tcpio -iuv <\"$GIT_DIR/MERGE_SAVE\"\n+\tgit-update-index --refresh >/dev/null\n }\n \n summary() {\n@@ -92,7 +103,7 @@ case \"$#,$common\" in\n \t# If head can reach all the merge then we are up to date.\n \t# but first the most common case of merging one remote\n \techo \"Already up-to-date. Yeeah!\"\n-\tdropheads\n+\tdropsave\n \texit 0\n \t;;\n 1,\"$head\")\n@@ -102,7 +113,7 @@ case \"$#,$common\" in\n \tgit-read-tree -u -m $head \"$1\" || exit 1\n \tgit-rev-parse --verify \"$1^0\" > \"$GIT_DIR/HEAD\"\n \tsummary \"$1\"\n-\tdropheads\n+\tdropsave\n \texit 0\n \t;;\n 1,*)\n@@ -124,29 +135,51 @@ case \"$#,$common\" in\n \tif test \"$up_to_date\" = t\n \tthen\n \t\techo \"Already up-to-date. Yeeah!\"\n-\t\tdropheads\n+\t\tdropsave\n \t\texit 0\n \tfi\n \t;;\n esac\n \n-# At this point we need a real merge.  Require that the tree matches\n-# exactly our head.\n \n-git-update-index --refresh &&\n-test '' = \"`git-diff-index --cached --name-only $head`\" || {\n-\tdie \"Need real merge but the working tree has local changes.\"\n-}\n+# At this point, we need a real merge.  No matter what strategy\n+# we use, it would operate on the index, possibly affecting the\n+# working tree, and when resolved cleanly, have the desired tree\n+# in the index -- this means that the index must be in sync with\n+# the $head commit.\n+files=$(git-diff-index --cached --name-only $head) || exit\n+if [ \"$files\" ]; then\n+   echo >&2 \"Dirty index: cannot merge (dirty: $files)\"\n+   exit 1\n+fi\n+\n+case \"$use_strategies\" in\n+?*' '?*)\n+    # Stash away the local changes so that we can try more than one.\n+    savestate\n+    single_strategy=no\n+    ;;\n+*)\n+    single_strategy=yes\n+    ;;\n+esac\n \n result_tree= best_cnt=-1 best_strategy= wt_strategy=\n for strategy in $use_strategies\n do\n     test \"$wt_strategy\" = '' || {\n \techo \"Rewinding the tree to pristine...\"\n-\tgit reset --hard $head\n+\trestorestate\n     }\n-    echo \"Trying merge strategy $strategy...\"\n+    case \"$single_strategy\" in\n+    no)\n+\techo \"Trying merge strategy $strategy...\"\n+\t;;\n+    esac\n+\n+    # Remember which strategy left the state in the working tree\n     wt_strategy=$strategy\n+\n     git-merge-$strategy $common -- $head \"$@\" || {\n \n \t# The backend exits with 1 when conflicts are left to be resolved,\n@@ -185,14 +218,14 @@ then\n     echo \"Committed merge $result_commit, made by $wt_strategy.\"\n     echo $result_commit >\"$GIT_DIR/HEAD\"\n     summary $result_commit\n-    dropheads\n+    dropsave\n     exit 0\n fi\n \n # Pick the result from the best strategy and have the user fix it up.\n case \"$best_strategy\" in\n '')\n-\tgit reset --hard $head\n+\trestorestate\n \tdie \"No merge strategy handled the merge.\"\n \t;;\n \"$wt_strategy\")\n@@ -200,7 +233,7 @@ case \"$best_strategy\" in\n \t;;\n *)\n \techo \"Rewinding the tree to pristine...\"\n-\tgit reset --hard $head\n+\trestorestate\n \techo \"Using the $best_strategy to prepare resolving by hand.\"\n \tgit-merge-$best_strategy $common -- $head \"$@\"\n \t;;\n"},{"id":"9158","messageId":"7vr7bgdup0.fsf@assigned-by-dhcp.cox.net","threadId":"1917","inReplyTo":"Pine.LNX.4.58.0509221500150.2553@g5.osdl.org","subject":"[PATCH] Use git-merge in git-pull (second try).","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-23T09:01:15Z","receivedAt":"2005-09-23T09:01:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This again makes git-pull to use git-merge, so that different merge\nstrategy can be specified from the command line.  Without explicit\nstrategy parameter, it defaults to git-merge-resolve if only one\nremote is pulled, and git-merge-octopus otherwise, to keep the\ndefault behaviour of the command the same as the original.\n\nAlso this brings another usability measure: -n flag from the command\nline, if given, is passed to git-merge to prevent it from running the\ndiffstat at the end of the merge.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n I tested this at least once with a dirty working tree ;-).  The\n main difference from the one that was backed out is that only\n one strategy is used by default -- this is to avoid any\n 'stashing away old states' done on the git-merge side.\n\n git-pull.sh |   48 ++++++++++++++++++++++++++++++++++++++++++++----\n 1 files changed, 44 insertions(+), 4 deletions(-)\n\n9c078a16523a2aae224a99e70f41eeb3d05a470c\ndiff --git a/git-pull.sh b/git-pull.sh\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -6,6 +6,38 @@\n \n . git-sh-setup || die \"Not a git archive\"\n \n+usage () {\n+    die \"git pull [-n] [-s strategy]... <repo> <head>...\"\n+}\n+\n+strategy_args= no_summary=\n+while case \"$#,$1\" in 0) break ;; *,-*) ;; *) break ;; esac\n+do\n+\tcase \"$1\" in\n+\t-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\\\n+\t\t--no-summa|--no-summar|--no-summary)\n+\t\tno_summary=-n ;;\n+\t-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\\\n+\t\t--strateg=*|--strategy=*|\\\n+\t-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)\n+\t\tcase \"$#,$1\" in\n+\t\t*,*=*)\n+\t\t\tstrategy=`expr \"$1\" : '-[^=]*=\\(.*\\)'` ;;\n+\t\t1,*)\n+\t\t\tusage ;;\n+\t\t*)\n+\t\t\tstrategy=\"$2\"\n+\t\t\tshift ;;\n+\t\tesac\n+\t\tstrategy_args=\"${strategy_args}-s $strategy \"\n+\t\t;;\n+\t-*)\n+\t\tusage\n+\t\t;;\n+\tesac\n+\tshift\n+done\n+\n orig_head=$(cat \"$GIT_DIR/HEAD\") || die \"Pulling into a black hole?\"\n git-fetch --update-head-ok \"$@\" || exit 1\n \n@@ -31,11 +63,19 @@ case \"$merge_head\" in\n \techo >&2 \"No changes.\"\n \texit 0\n \t;;\n-*' '?*)\n-\techo >&2 \"Pulling more than one heads; making an Octopus.\"\n-\texec git-octopus\n+?*' '?*)\n+\tstrategy_default_args='-s octopus'\n+\t;;\n+*)\n+\tstrategy_default_args='-s resolve'\n+\t;;\n+esac\n+\n+case \"$strategy_args\" in\n+'')\n+\tstrategy_args=$strategy_default_args\n \t;;\n esac\n \n merge_name=$(git-fmt-merge-msg <\"$GIT_DIR/FETCH_HEAD\")\n-git-resolve \"$(cat \"$GIT_DIR\"/HEAD)\" $merge_head \"$merge_name\"\n+git-merge $no_summary $strategy_args \"$merge_name\" HEAD $merge_head\n"}]}