{"thread":{"id":"9886","subject":"rename detection limit checking, cherry picking, and git am -3","startedAt":"2007-09-17T03:32:31Z","lastAt":"2007-09-18T00:18:27Z","messageCount":5,"participants":["Mark Levedahl","Shawn O. Pearce","Junio C Hamano","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"53252","messageId":"46EDF54F.5030503@gmail.com","threadId":"9886","inReplyTo":null,"subject":"rename detection limit checking, cherry picking, and git am -3","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2007-09-17T03:32:31Z","receivedAt":"2007-09-17T03:32:31Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"Linus' recent patch to invoke limiting on rename detection broke my \nability to use cherry-picking on one project. This project has about \n4300 files on one branch (a), 2500 on a later branch (b), 226 commits in \ntotal between the two branches, and a convoluted history of how branch a \nmorphed into branch b. About 50 files were renamed in the transition, \nand we need to migrate patches from the still maintained branch a onto \nthe new branch b.\n\nPrior to Linus' recent patch to limit rename detection (0024a549), \ncherry picking a patch from a to b, where the patch affected just one \nfile, often took about 45 seconds on a 3 GHz pentium 4 with the CPU \npegged at 100% for the duration. The cherry picking always succeeded and \ncorrectly followed renames, but was very slow.\n\nFollowing Linus' patch, the cherry picking fails with a merge conflict \n(almost instantly), complaining the file has been deleted on b but \nmodified on a, i.e., the rename detection does not work. I tried raising \ndiff.renameLimit to 100000, that seems to have no effect whatsoever on \ncherry-pick (the process aborts with a conflict almost immediately).\n\nCuriously, using \"git format-patch x..y --stdout | git am -3\" succeeds \nin this case, and runs in well less than a second. This performance \nseems unchanged by the rename detection limit patch.\n\nSo, the rename limit patch \"broke\" git for this usage, though one could \nreasonably argue the previous code was so slow as to be broken anyway.\n\nThe curious thing to me is the vast superiority of whatever \ngit-format-patch|git-am -3 does, and I wonder if that isn't a \nfundementally better design for cherry picking than git-cherry-pick \nimplements (it obviously is for this case).\n\nMark\n"},{"id":"53253","messageId":"20070917034742.GG3099@spearce.org","threadId":"9886","inReplyTo":"46EDF54F.5030503@gmail.com","subject":"Re: rename detection limit checking, cherry picking, and git am -3","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-09-17T03:47:42Z","receivedAt":"2007-09-17T03:47:42Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Mark Levedahl wrote:\n> The curious thing to me is the vast superiority of whatever \n> git-format-patch|git-am -3 does, and I wonder if that isn't a \n> fundementally better design for cherry picking than git-cherry-pick \n> implements (it obviously is for this case).\n\nIn this case `git am -3` creates a tree object containing only\nthe files modified by the patch and then feeds that tree into\ngit-merge-recursive. Now if you go study git-revert's code you'll\nsee it actually just calls git-merge-recursive on three trees,\nbut these are three complete trees.\n\nSo what's probably happening here is there's less candidates on one\nside in the `am -3` case, so we spend a lot less time generating\nthe rename matrix, searching for a match, and we get better changes\nof finding a match.\n\nI actually don't see why cherry-pick can't be defined in terms\nof `format-patch|am -3`. It probably would be faster in almost\nall cases.\n\n-- \nShawn.\n"},{"id":"53255","messageId":"7v3axd5325.fsf@gitster.siamese.dyndns.org","threadId":"9886","inReplyTo":"20070917034742.GG3099@spearce.org","subject":"Re: rename detection limit checking, cherry picking, and git am -3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-17T04:27:46Z","receivedAt":"2007-09-17T04:27:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> I actually don't see why cherry-pick can't be defined in terms\n> of `format-patch|am -3`. It probably would be faster in almost\n> all cases.\n\nHeh, people often suggested that rebase should get --merge as\ndefault, and I resisted that.\n\nI think it would make sense to do the consolidated backend for\nrebase, revert, cherry-pick and am (I have been tentatively\ncalling this \"git replay\") primarily based on the \"patch with\nfallback to 3-way\" like format-patch piped to \"am -3\", with an\noption to do merge-recursive.\n"},{"id":"53293","messageId":"20070917095829.GD8657@diana.vm.bytemark.co.uk","threadId":"9886","inReplyTo":"7v3axd5325.fsf@gitster.siamese.dyndns.org","subject":"Re: rename detection limit checking, cherry picking, and git am -3","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-09-17T09:58:29Z","receivedAt":"2007-09-17T09:58:29Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-09-16 21:27:46 -0700, Junio C Hamano wrote:\n\n> I think it would make sense to do the consolidated backend for\n> rebase, revert, cherry-pick and am (I have been tentatively calling\n> this \"git replay\") primarily based on the \"patch with fallback to\n> 3-way\" like format-patch piped to \"am -3\", with an option to do\n> merge-recursive.\n\nI guess such a backend would be useful for StGit as well.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"53381","messageId":"46EF1953.6060106@gmail.com","threadId":"9886","inReplyTo":"20070917034742.GG3099@spearce.org","subject":"Re: rename detection limit checking, cherry picking, and git am -3","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2007-09-18T00:18:27Z","receivedAt":"2007-09-18T00:18:27Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"Shawn O. Pearce wrote:\n> In this case `git am -3` creates a tree object containing only\n> the files modified by the patch and then feeds that tree into\n> git-merge-recursive. Now if you go study git-revert's code you'll\n> see it actually just calls git-merge-recursive on three trees,\n> but these are three complete trees.\n>\n> So what's probably happening here is there's less candidates on one\n> side in the `am -3` case, so we spend a lot less time generating\n> the rename matrix, searching for a match, and we get better changes\n> of finding a match.\n>\n> \nThanks for the explanation. For my case, there are < 500 files \n(including renamed files) in common between the two branches, giving \n~2000*4000 files that have no correspondence for which git can try to \nfind renames. Clearly, reducing the one side from 4000 files to 1 file \nhas an enormous payoff.\n\nMark\n"}]}