{"thread":{"id":"6136","subject":"Why git-merge-resolve in git-am?","startedAt":"2006-12-28T01:45:25Z","lastAt":"2006-12-28T07:48:58Z","messageCount":5,"participants":["Shawn Pearce","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30388","messageId":"20061228014525.GC16612@spearce.org","threadId":"6136","inReplyTo":null,"subject":"Why git-merge-resolve in git-am?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T01:45:25Z","receivedAt":"2006-12-28T01:45:25Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Why does git-am use git-merge-resolve while git-rebase -m uses\ngit-merge-recursive?\n\nCan we just change git-am to use git-merge-recursive instead?\nFor one thing its faster, for another it supports the GITHEAD_*\nfeature for naming the hunks in a conflict.\n\n-- \nShawn.\n"},{"id":"30390","messageId":"7vr6uk3h2p.fsf@assigned-by-dhcp.cox.net","threadId":"6136","inReplyTo":"20061228014525.GC16612@spearce.org","subject":"Re: Why git-merge-resolve in git-am?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T02:11:26Z","receivedAt":"2006-12-28T02:11:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Why does git-am use git-merge-resolve while git-rebase -m uses\n> git-merge-recursive?\n\nThe use of merge-resolve by am predates merge-resolve became\nusable by at least six weeks, and longer before merge-resolve\nbecame really stable for about an extra month after.\n\nEven after it stabilized merge-recursive was way slower than\nmerge-resove until it was rewritten in C for another nine\nmonths.\n"},{"id":"30392","messageId":"20061228022038.GE16612@spearce.org","threadId":"6136","inReplyTo":"7vr6uk3h2p.fsf@assigned-by-dhcp.cox.net","subject":"Re: Why git-merge-resolve in git-am?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T02:20:38Z","receivedAt":"2006-12-28T02:20:38Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Shawn Pearce writes:\n> \n> > Why does git-am use git-merge-resolve while git-rebase -m uses\n> > git-merge-recursive?\n> \n> The use of merge-resolve by am predates merge-resolve became\n> usable by at least six weeks, and longer before merge-resolve\n> became really stable for about an extra month after.\n> \n> Even after it stabilized merge-recursive was way slower than\n> merge-resove until it was rewritten in C for another nine\n> months.\n\nGood reasons, but all are strictly historical. So there's actually\nno technical reason we can't use merge-recursive here in git-am.\n\nBasically I'm trying to improve the merge conflict hunks in\n`git-am -3`. merge-recursive now recognizes GITHEAD_* but\nmerge-one-file doesn't (and can't). Switching to merge-recursive\nand setting GITHEAD_* would get that case fixed in git-rebase\nwithout -m.\n\n-- \nShawn.\n"},{"id":"30393","messageId":"7virfw3gb2.fsf@assigned-by-dhcp.cox.net","threadId":"6136","inReplyTo":"20061228022038.GE16612@spearce.org","subject":"Re: Why git-merge-resolve in git-am?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T02:28:01Z","receivedAt":"2006-12-28T02:28:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Good reasons, but all are strictly historical. So there's actually\n> no technical reason we can't use merge-recursive here in git-am.\n\nA very early version of recursive was unusable (it did not pay\nattention to the merge base the caller gave it and tried to\nalways compute it by itself), but that was fixed sometime later.\n\nI do not recall offhand C version still has that fix (I think it\ndoes but you should double check); as long ias it honors the\nmerge base the caller computed, it should be Ok to replace\nresolve with recursive. Go wild.\n"},{"id":"30416","messageId":"20061228074857.GC17304@spearce.org","threadId":"6136","inReplyTo":"7virfw3gb2.fsf@assigned-by-dhcp.cox.net","subject":"Re: Why git-merge-resolve in git-am?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T07:48:58Z","receivedAt":"2006-12-28T07:48:58Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Shawn Pearce writes:\n> \n> > Good reasons, but all are strictly historical. So there's actually\n> > no technical reason we can't use merge-recursive here in git-am.\n> \n> A very early version of recursive was unusable (it did not pay\n> attention to the merge base the caller gave it and tried to\n> always compute it by itself), but that was fixed sometime later.\n> \n> I do not recall offhand C version still has that fix (I think it\n> does but you should double check); as long ias it honors the\n> merge base the caller computed, it should be Ok to replace\n> resolve with recursive. Go wild.\n\nI checked. It does use the merge base supplied by the caller,\nbut only if the caller supplies only one merge base. Otherwise it\ncomputes its own.\n\nThis isn't a problem for git-am as we only supply one merge base.\nWhat was a problem was git-am supplies trees, not commits, and the\ncode internally uses commits. I fixed that in patch 9/11 'Allow\nmerging bare trees' in my recent series.\n\n-- \nShawn.\n"}]}