{"thread":{"id":"37718","subject":"Performance Issues with Git Rebase","startedAt":"2014-10-12T01:29:32Z","lastAt":"2014-10-13T17:52:00Z","messageCount":3,"participants":["Crabtree, Andrew","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"250519","messageId":"B82B660D4887C042850326C2BC65FE035D56CA14@G4W3227.americas.hpqcorp.net","threadId":"37718","inReplyTo":null,"subject":"Performance Issues with Git Rebase","fromName":"Crabtree, Andrew","fromEmail":"andrew.crabtree@hp.com","sentAt":"2014-10-12T01:29:32Z","receivedAt":"2014-10-12T01:29:32Z","isPatch":false,"sender":{"key":"andrew.crabtree@hp.com","avatar":null},"body":"I have what appears to be a fairly straightforward rebase operation and I can't figure out why it seems to effectively hang 'git rebase'.\n\nI have a handful of commits that I made last summer and haven't touched since.  I'm trying to rebase them against latest on upstream.\n\ngit status\nOn branch git_enhancements\nYour branch and 'origin/smb' have diverged,\nand have 4 and 4665 different commits each, respectively.\n  (use \"git pull\" to merge the remote branch into yours)\n\nIf at this moment I type \"git rebase\" it will print out \n\nFirst, rewinding head to replay your work on top of it...\n\nAnd then nothing will happen for approximately 30 minutes, and then it will complete.\n  \nIf I instead type \"git rebase --onto @{u} HEAD~4\" it completes immediately.\n\nI've narrowed it down to this line in git-rebase--am (approx. line 65)\n\n\tgit format-patch -k --stdout --full-index --cherry-pick --right-only \\\n\t\t--src-prefix=a/ --dst-prefix=b/ --no-renames --no-cover-letter \\\n\t\t\"$revisions\" ${restrict_revision+^$restrict_revision} \\\n\t\t>\"$GIT_DIR/rebased-patches\"\n\nWhich is turned into this in my particular case\n\ngit format-patch -k --stdout --full-index --cherry-pick --right-only --src-prefix=a/ --dst-prefix=b/ --no-renames --no-cover-letter 451da4975b25797fe54cd11e4796bbd3ee0911ce...ea3cf673d0e76504738bf130d48148d5b96cc406\n\nIf I time just that command I get \n\nreal        32m10.324s\nuser       26m21.296s\nsys          0m28.994s\n\n\nIf I change the triple do to a double dot I get \n\nreal        0m4.276s\nuser       0m0.096s\nsys          0m0.022s\n\nWhich is much more in line with how long I think the command should take.\n\nThe triple dot is coming from just earlier in the file here \n\nif test -z \"$rebase_root\"\n\t# this is now equivalent to ! -z \"$upstream\"\nthen\n\trevisions=$upstream...$orig_head\nelse\n\trevisions=$onto...$orig_head\nfi\n\nwhich seems to have been in place for 2+ years.  \n\nI'm getting the same output with both the triple and double dot for my specific case, but I have no idea if that change makes sense for all cases or not.  Any guidance? \n\nThanks much,\n-Andrew\n"},{"id":"250544","messageId":"xmqqlhoj51bi.fsf@gitster.dls.corp.google.com","threadId":"37718","inReplyTo":"B82B660D4887C042850326C2BC65FE035D56CA14@G4W3227.americas.hpqcorp.net","subject":"Re: Performance Issues with Git Rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-13T17:25:37Z","receivedAt":"2014-10-13T17:25:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Crabtree, Andrew\" <andrew.crabtree@hp.com> writes:\n\n> I'm getting the same output with both the triple and double dot for my\n> specific case, but I have no idea if that change makes sense for all\n> cases or not.  Any guidance?\n\nThe difference only matters if any of your 4 patches have been sent\nto your upstream and accepted and appear among the 4665 changes they\nhave.\n\nThe --cherry-pick option is about cross checking the combinations of\n4 x 4665 and filter out matching ones (if any).\n"},{"id":"250546","messageId":"B82B660D4887C042850326C2BC65FE035D56CD63@G4W3227.americas.hpqcorp.net","threadId":"37718","inReplyTo":"xmqqlhoj51bi.fsf@gitster.dls.corp.google.com","subject":"RE: Performance Issues with Git Rebase","fromName":"Crabtree, Andrew","fromEmail":"andrew.crabtree@hp.com","sentAt":"2014-10-13T17:52:00Z","receivedAt":"2014-10-13T17:52:00Z","isPatch":false,"sender":{"key":"andrew.crabtree@hp.com","avatar":null},"body":"Ah gotcha.  That makes sense.\n\nDefault behavior is to do a patch-id check on all of them which is exactly what you would normally want to happen, and suppressing that speeds things up considerably at the risk of attempting to re-apply an already existing patch.\n\nThanks much for the explanation.   Perhaps I'll add a progress indicator since my organization will be doing a significant number of these types of rebases in the near future.\n\nRegards,\n-Andrew\n\n\n\n\n> -----Original Message-----\n> From: Junio C Hamano [mailto:gitster@pobox.com]\n> Sent: Monday, October 13, 2014 10:26 AM\n> To: Crabtree, Andrew\n> Cc: git@vger.kernel.org\n> Subject: Re: Performance Issues with Git Rebase\n> \n> \"Crabtree, Andrew\" <andrew.crabtree@hp.com> writes:\n> \n> > I'm getting the same output with both the triple and double dot for my\n> > specific case, but I have no idea if that change makes sense for all\n> > cases or not.  Any guidance?\n> \n> The difference only matters if any of your 4 patches have been sent\n> to your upstream and accepted and appear among the 4665 changes they\n> have.\n> \n> The --cherry-pick option is about cross checking the combinations of\n> 4 x 4665 and filter out matching ones (if any).\n> \n"}]}