{"thread":{"id":"26837","subject":"git cherry improvements suggestions","startedAt":"2011-03-23T08:11:24Z","lastAt":"2011-03-24T07:47:11Z","messageCount":9,"participants":["Piotr Krukowiecki","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"164116","messageId":"AANLkTimk0bkOGVy2W+XddHRuf-1xw+d0RwzPhnk40vi8@mail.gmail.com","threadId":"26837","inReplyTo":null,"subject":"git cherry improvements suggestions","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-03-23T08:11:24Z","receivedAt":"2011-03-23T08:11:24Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"Hi,\n\nShort version:\n\n1. The <limit> is misleading IMO\n2. Please extend the output to show \"full diff\"\n3. Please add numerical/time <limit>\n4. Would it be possible to use \"=\" for \"equivalent change\"?\n\nPlease tell me your opinions.\n\n\nLong version:\n\nI have a branch that have diverged long time ago from main branch. I can't use\nmerge, so I'm using cherry-pick to transplant changes between branches\n(the other reason is I'm using git-svn...)\n\nI noticed I did not transplant a certain commit recently. I wanted to\nsee if there\nare any other commits I didn't transplant. I tried using git cherry:\n\n\n1. man page says: git cherry [-v] [<upstream> [<head> [<limit>]]]\n\n   $ git cherry -v master 9_1 20\n   fatal: Unknown commit 20\n\nAfter reading man page I though the limit is a numeric limit, like \"check\nlast 20 commits\".\n\nI just realized it is a commit sha1. I think man could be improved to explicitly\nsay it's sha1 - maybe change the name from <limit> to something else\n(<sha1>? <sha1_limit>?)\n\n\n2. The cherry currently shows only changes against one branch:\n\n   Every commit that doesn’t exist in the <upstream> branch has its id (sha1)\n   reported[...] The ones that have equivalent change already in the <upstream>\n   branch are prefixed with a minus (-) sign, and those that only exist in the\n   <head> branch are prefixed with a plus (+)  symbol\n\nSo it will not show commits that exist only in <upstream> but not in <head>.\n\nIn my case changes are transplanted both ways (in general), so I have to check\nboth branches.\n\nI understand I can switch branch positions, but this requires post-processing\nto get rid of equivalent commits, maybe something like this:.\n\n    git cherry upstream head | grep '^[+]' > head_only\n    git cherry head upstream | grep '^[+]' > upstream_only\n\nThis is not very convenient, and I think you won't be able to see transplanted\nchanges with different ids (e.g. with conflicts) next to each other (such\ncommits would have probably the same commit message and it's possible\nthey were done at the same/close time, so it should be easy to see that\nalthough the commits are shown as different, they represent the same change)\n\nI think it would be usable to be able to see all changes:\n    - commits in upstream only\n    - commits in head only\n    - equivalent commits (in both upstream and head)\n\nNot sure how it should act in case of <limit> - maybe it should be illegal\nto use <limit> in this mode. See also next point.\n\n\n3. I think a numerical limit (or even: time limit etc) of checked commits would\nbe useful, especially in \"full diff\" mode. Without it would be not\npossible to do a\nfull diff with a limit, and when switching branch positions you'd have to lookup\ntwo commits:\n\n    <find commit on head>\n    git cherry upstream head  head_limit | grep '^[+]' > head_only\n    <find commit on upstream>\n    git cherry head upstream upstream_limit | grep '^[+]' > upstream_only\n\nIn case of numerical <limit> it should probably take <limit> changes\nfrom head and\n<limit> changes from upstream and see what is their status. So the actual\noutput would list from <limit> to 2*<limit> commits depending if all\ncommits are on\nboth branches, or no commit is equal.\n\n\n4. The output format uses \"-\" to show commits that exist in both branches.\nI find this unnatural. There probably is a reason for this? But maybe it would\nbe possible to change the symbols? For example:\n\n   - commit in upstream only\n   + commit in head only\n   = equivalent commit\n\nOr \"<\", \">\", \" \" or any other graphic symbol.\n\n\nThanks for you time reading this long post :)\n\n-- \nPiotr Krukowiecki\n"},{"id":"164126","messageId":"4D89CF8E.4070100@drmicha.warpmail.net","threadId":"26837","inReplyTo":"AANLkTimk0bkOGVy2W+XddHRuf-1xw+d0RwzPhnk40vi8@mail.gmail.com","subject":"Re: git cherry improvements suggestions","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-23T10:46:38Z","receivedAt":"2011-03-23T10:46:38Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Piotr Krukowiecki venit, vidit, dixit 23.03.2011 09:11:\n> Hi,\n> \n> Short version:\n> \n> 1. The <limit> is misleading IMO\n\nIn what way? Is the documentation wrong?\n\n> 2. Please extend the output to show \"full diff\"\n> 3. Please add numerical/time <limit>\n> 4. Would it be possible to use \"=\" for \"equivalent change\"?\n> \n> Please tell me your opinions.\n\nYou will be a happy user of \"git log --cherry A...B\" instead of \"git\ncherry A B\". It gives you all the log option (e.g. p for diff) that you\nlike and uses \"=\" rather than \"-\". It's currently in next and will be in\nthe next release.\n\n> \n> \n> Long version:\n> \n> I have a branch that have diverged long time ago from main branch. I can't use\n> merge, so I'm using cherry-pick to transplant changes between branches\n> (the other reason is I'm using git-svn...)\n> \n> I noticed I did not transplant a certain commit recently. I wanted to\n> see if there\n> are any other commits I didn't transplant. I tried using git cherry:\n> \n> \n> 1. man page says: git cherry [-v] [<upstream> [<head> [<limit>]]]\n> \n>    $ git cherry -v master 9_1 20\n>    fatal: Unknown commit 20\n> \n> After reading man page I though the limit is a numeric limit, like \"check\n> last 20 commits\".\n\nIt clearly is the name of a commit in that picture.\n\n> \n> 2. The cherry currently shows only changes against one branch:\n> \n>    Every commit that doesn’t exist in the <upstream> branch has its id (sha1)\n>    reported[...] The ones that have equivalent change already in the <upstream>\n>    branch are prefixed with a minus (-) sign, and those that only exist in the\n>    <head> branch are prefixed with a plus (+)  symbol\n> \n> So it will not show commits that exist only in <upstream> but not in <head>.\n> \n> In my case changes are transplanted both ways (in general), so I have to check\n> both branches.\n\nYou'll be a happy user of \"git log --cherry-mark --left-right A...B\" :)\n\n\n> 3. I think a numerical limit (or even: time limit etc) of checked commits would\n> be useful, especially in \"full diff\" mode. Without it would be not\n\nlog has a limit argument (-<number>), though I'm not sure it is exactly\nwhat you want.\n\n\n> 4. The output format uses \"-\" to show commits that exist in both branches.\n> I find this unnatural. There probably is a reason for this? But maybe it would\n> be possible to change the symbols? For example:\n> \n>    - commit in upstream only\n>    + commit in head only\n>    = equivalent commit\n> \n> Or \"<\", \">\", \" \" or any other graphic symbol.\n\ngit log --cherry-mark --left-right will use <,=,>\ngit log --cherry-mark or --cherry will use *,=\n\n(And yes, you can use it with --graph!)\n\nCheers,\nMichael\n"},{"id":"164138","messageId":"AANLkTinXh_Y9ft5Pd5SxOEXvKNm3HLmsiut8WrvFZrdQ@mail.gmail.com","threadId":"26837","inReplyTo":"4D89CF8E.4070100@drmicha.warpmail.net","subject":"Re: git cherry improvements suggestions","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-03-23T13:23:13Z","receivedAt":"2011-03-23T13:23:13Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Wed, Mar 23, 2011 at 11:46 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 09:11:\n>> Hi,\n>>\n>> Short version:\n>>\n>> 1. The <limit> is misleading IMO\n>\n> In what way? Is the documentation wrong?\n\nNo, but for me <limit> looks like numeric limit. There is no explicit note in\nman page that it's a commit.\n\n\n>> 2. Please extend the output to show \"full diff\"\n>> 3. Please add numerical/time <limit>\n>> 4. Would it be possible to use \"=\" for \"equivalent change\"?\n>>\n>> Please tell me your opinions.\n>\n> You will be a happy user of \"git log --cherry A...B\" instead of \"git\n> cherry A B\". It gives you all the log option (e.g. p for diff) that you\n> like and uses \"=\" rather than \"-\". It's currently in next and will be in\n> the next release.\n\nI've tried it and indeed I'm happy! :)\nThe \"git log --cherry-mark --left-right A...B\" is what I needed!\n\nJust some stats:\n\n   git log --cherry-mark --left-right --oneline --date-order branch...trunk\n\nlists 1004 commits, takes about 20s and memory peaks to about 670MB\ntwice during the run (I'm on linux with AMD Phenom II X4 945)\n\nWith limit it prints X last commits (the limiting seems to take place after all\nwork, on the output list only).\n\nbranch..trunk is 551 commits, the other way is 453 commits.\n710 commits are found to be \"=\", 98 \"<\", 196 \">\".\n\nNote, I'm not saying it's too slow, or that it's working incorrectly, I'm just\ngiving real-life stats if anyone was interested.\nI suspect such checks won't be done frequently.\n\nSo thanks for the great improvement!\n\n\n>> 1. man page says: git cherry [-v] [<upstream> [<head> [<limit>]]]\n>>\n>>    $ git cherry -v master 9_1 20\n>>    fatal: Unknown commit 20\n>>\n>> After reading man page I though the limit is a numeric limit, like \"check\n>> last 20 commits\".\n>\n> It clearly is the name of a commit in that picture.\n\nI have assumed the limit is numerical and means number of commits.\nComing from that assumption it looked like cherry used the limit number\nas a commit by mistake.\n\n\n\n>> 2. The cherry currently shows only changes against one branch:\n>>\n>>    Every commit that doesn’t exist in the <upstream> branch has its id (sha1)\n>>    reported[...] The ones that have equivalent change already in the <upstream>\n>>    branch are prefixed with a minus (-) sign, and those that only exist in the\n>>    <head> branch are prefixed with a plus (+)  symbol\n>>\n>> So it will not show commits that exist only in <upstream> but not in <head>.\n>>\n>> In my case changes are transplanted both ways (in general), so I have to check\n>> both branches.\n>\n> You'll be a happy user of \"git log --cherry-mark --left-right A...B\" :)\n\nThanks again :)\n\n\n>> 3. I think a numerical limit (or even: time limit etc) of checked commits would\n>> be useful, especially in \"full diff\" mode. Without it would be not\n>\n> log has a limit argument (-<number>), though I'm not sure it is exactly\n> what you want.\n\nI'd be happy if the limiting was done before all the work, so the performance\ncould be improved by that.\n\nFor example, it could take <number> last commits from each branch and check\nonly them.\n\nThis would help if you wanted to check only last week commits.\n\n\n>> 4. The output format uses \"-\" to show commits that exist in both branches.\n>> I find this unnatural. There probably is a reason for this? But maybe it would\n>> be possible to change the symbols? For example:\n>>\n>>    - commit in upstream only\n>>    + commit in head only\n>>    = equivalent commit\n>>\n>> Or \"<\", \">\", \" \" or any other graphic symbol.\n>\n> git log --cherry-mark --left-right will use <,=,>\n> git log --cherry-mark or --cherry will use *,=\n>\n> (And yes, you can use it with --graph!)\n\n\n\nI've done some quick tests to see how --cherry works, maybe someone\nwill find them useful:\n\n# setup\n$ echo a > a && git add a && git commit -a -m a\n$ echo b > b && git add b && git commit -a -m b\n$ echo a1 > a && git add a1 && git commit -a -m a1\n$ echo a1 > a && git add a && git commit -a -m a1\n$ git checkout -b topic HEAD^\n$ echo b1 > b && git add b && git commit -a -m b1\n$ echo c > c && git add c && git commit -a -m c\n$ git checkout master\n$ echo d > d && git add d && git commit -a -m d\n\n# cherry pick a1 into topic and b1 into master\n\n$ git log --oneline --graph topic master\n* b1f200c a1\n* 6b95eb4 c\n* ab34325 b1\n| * 15ff34f b1\n| * d78c15d d\n| * ace8ef2 a1\n|/\n* 9d88558 b\n* bd17dd4 a\n\n$ git log --oneline --cherry topic...master\n= 15ff34f b1\n+ d78c15d d\n= ace8ef2 a1\n\n$ git log --oneline --cherry master...topic\n= b1f200c a1\n+ 6b95eb4 c\n= ab34325 b1\n\n$ git log --oneline --cherry -2 topic...master\n= 15ff34f b1\n+ d78c15d d\n\n$ git log --oneline --cherry -2 master...topic\n= b1f200c a1\n+ 6b95eb4 c\n\n\n$ git cherry topic master\n- ace8ef21d85b060b98d3f7d8a3b3753ee9b98317\n+ d78c15df0ee457f77dab7b0b247735dfec246b65\n- 15ff34f8a342b6e8999d0e5d528e0b8875fb8042\n\n$ git cherry master topic\n- ab343256684621d5bc68084f1d77f1b8312b6a3b\n+ 6b95eb4c01647de623f478219eb932b07b97edc6\n- b1f200c49c562517eafd77872bf5394960eee53f\n\n\n-- \nPiotr Krukowiecki\n"},{"id":"164140","messageId":"4D89F6BC.2040902@drmicha.warpmail.net","threadId":"26837","inReplyTo":"AANLkTinXh_Y9ft5Pd5SxOEXvKNm3HLmsiut8WrvFZrdQ@mail.gmail.com","subject":"Re: git cherry improvements suggestions","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-23T13:33:48Z","receivedAt":"2011-03-23T13:33:48Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23:\n> On Wed, Mar 23, 2011 at 11:46 AM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n...\n>> You will be a happy user of \"git log --cherry A...B\" instead of \"git\n>> cherry A B\". It gives you all the log option (e.g. p for diff) that you\n>> like and uses \"=\" rather than \"-\". It's currently in next and will be in\n>> the next release.\n> \n> I've tried it and indeed I'm happy! :)\n> The \"git log --cherry-mark --left-right A...B\" is what I needed!\n> \n> Just some stats:\n> \n>    git log --cherry-mark --left-right --oneline --date-order branch...trunk\n> \n> lists 1004 commits, takes about 20s and memory peaks to about 670MB\n> twice during the run (I'm on linux with AMD Phenom II X4 945)\n> \n> With limit it prints X last commits (the limiting seems to take place after all\n> work, on the output list only).\n> \n> branch..trunk is 551 commits, the other way is 453 commits.\n> 710 commits are found to be \"=\", 98 \"<\", 196 \">\".\n> \n> Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just\n> giving real-life stats if anyone was interested.\n> I suspect such checks won't be done frequently.\n\nYou don't need to say it's slow - I've said so already :(\n\nhttp://permalink.gmane.org/gmane.comp.version-control.git/169725\n\nBut I hope we can remove some bottle-necks.\n\n> So thanks for the great improvement!\n\nYou're welcome :)\n\nMichael\n"},{"id":"164147","messageId":"AANLkTin7Du5RYt946hNjP-y53puNykebCjiKk5Ju_igr@mail.gmail.com","threadId":"26837","inReplyTo":"4D89F6BC.2040902@drmicha.warpmail.net","subject":"Re: git cherry improvements suggestions","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-03-23T14:43:36Z","receivedAt":"2011-03-23T14:43:36Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Wed, Mar 23, 2011 at 2:33 PM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23:\n>> Just some stats:\n>>\n>>    git log --cherry-mark --left-right --oneline --date-order branch...trunk\n>>\n>> lists 1004 commits, takes about 20s and memory peaks to about 670MB\n>> twice during the run (I'm on linux with AMD Phenom II X4 945)\n>>\n>> With limit it prints X last commits (the limiting seems to take place after all\n>> work, on the output list only).\n>>\n>> branch..trunk is 551 commits, the other way is 453 commits.\n>> 710 commits are found to be \"=\", 98 \"<\", 196 \">\".\n>>\n>> Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just\n>> giving real-life stats if anyone was interested.\n>> I suspect such checks won't be done frequently.\n>\n> You don't need to say it's slow - I've said so already :(\n>\n> http://permalink.gmane.org/gmane.comp.version-control.git/169725\n\nIn the link above:\n  git cherry A B: 0.4s\n  git rev-list --cherry A...B: 1.7s\n\nSo rev-list is 4.25x slower.\n\nIn my case it's only 1.23x slower:\n\n   $ time git rev-list --cherry branch...trunk  > /tmp/rev-list\n   real\t0m18.627s\n   user\t0m17.710s\n   sys\t0m0.900s\n\n   $ time git cherry  branch trunk  > /tmp/cherry\n   real\t0m15.345s\n   user\t0m14.310s\n   sys\t0m1.020s\n\n\n-- \nPiotr Krukowiecki\n"},{"id":"164149","messageId":"4D8A0741.9000506@drmicha.warpmail.net","threadId":"26837","inReplyTo":"AANLkTin7Du5RYt946hNjP-y53puNykebCjiKk5Ju_igr@mail.gmail.com","subject":"Re: git cherry improvements suggestions","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-23T14:44:17Z","receivedAt":"2011-03-23T14:44:17Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Piotr Krukowiecki venit, vidit, dixit 23.03.2011 15:43:\n> On Wed, Mar 23, 2011 at 2:33 PM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n>> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23:\n>>> Just some stats:\n>>>\n>>>    git log --cherry-mark --left-right --oneline --date-order branch...trunk\n>>>\n>>> lists 1004 commits, takes about 20s and memory peaks to about 670MB\n>>> twice during the run (I'm on linux with AMD Phenom II X4 945)\n>>>\n>>> With limit it prints X last commits (the limiting seems to take place after all\n>>> work, on the output list only).\n>>>\n>>> branch..trunk is 551 commits, the other way is 453 commits.\n>>> 710 commits are found to be \"=\", 98 \"<\", 196 \">\".\n>>>\n>>> Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just\n>>> giving real-life stats if anyone was interested.\n>>> I suspect such checks won't be done frequently.\n>>\n>> You don't need to say it's slow - I've said so already :(\n>>\n>> http://permalink.gmane.org/gmane.comp.version-control.git/169725\n> \n> In the link above:\n>   git cherry A B: 0.4s\n>   git rev-list --cherry A...B: 1.7s\n> \n> So rev-list is 4.25x slower.\n> \n> In my case it's only 1.23x slower:\n> \n>    $ time git rev-list --cherry branch...trunk  > /tmp/rev-list\n>    real\t0m18.627s\n>    user\t0m17.710s\n>    sys\t0m0.900s\n> \n>    $ time git cherry  branch trunk  > /tmp/cherry\n>    real\t0m15.345s\n>    user\t0m14.310s\n>    sys\t0m1.020s\n> \n> \n\nHow's that with > /dev/null (or with --count for rev-list)? Also, how\nmany merge bases do you have:\n\ngit merge-base --all branch trunk | wc -l\n\nThanks!\nMichael\n"},{"id":"164181","messageId":"AANLkTi=7=QDh0Pe9W4bRcGY5Krg7sBqRcZ2C1YonJSRN@mail.gmail.com","threadId":"26837","inReplyTo":"4D8A0741.9000506@drmicha.warpmail.net","subject":"Re: git cherry improvements suggestions","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-03-23T19:28:02Z","receivedAt":"2011-03-23T19:28:02Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Wed, Mar 23, 2011 at 3:44 PM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 15:43:\n>> On Wed, Mar 23, 2011 at 2:33 PM, Michael J Gruber\n>> <git@drmicha.warpmail.net> wrote:\n>>> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23:\n>>>> Just some stats:\n>>>>\n>>>>    git log --cherry-mark --left-right --oneline --date-order branch...trunk\n>>>>\n>>>> lists 1004 commits, takes about 20s and memory peaks to about 670MB\n>>>> twice during the run (I'm on linux with AMD Phenom II X4 945)\n>>>>\n>>>> With limit it prints X last commits (the limiting seems to take place after all\n>>>> work, on the output list only).\n>>>>\n>>>> branch..trunk is 551 commits, the other way is 453 commits.\n>>>> 710 commits are found to be \"=\", 98 \"<\", 196 \">\".\n>>>>\n>>>> Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just\n>>>> giving real-life stats if anyone was interested.\n>>>> I suspect such checks won't be done frequently.\n>>>\n>>> You don't need to say it's slow - I've said so already :(\n>>>\n>>> http://permalink.gmane.org/gmane.comp.version-control.git/169725\n>>\n>> In the link above:\n>>   git cherry A B: 0.4s\n>>   git rev-list --cherry A...B: 1.7s\n>>\n>> So rev-list is 4.25x slower.\n>>\n>> In my case it's only 1.23x slower:\n>>\n>>    $ time git rev-list --cherry branch...trunk  > /tmp/rev-list\n>>    real       0m18.627s\n>>    user       0m17.710s\n>>    sys        0m0.900s\n>>\n>>    $ time git cherry  branch trunk  > /tmp/cherry\n>>    real       0m15.345s\n>>    user       0m14.310s\n>>    sys        0m1.020s\n>>\n>>\n>\n> How's that with > /dev/null (or with --count for rev-list)? Also, how\n> many merge bases do you have:\n>\n> git merge-base --all branch trunk | wc -l\n\nI expect only one - there should be no merges between those two\nbranches.\n\nI will do measurements tomorrow.\n\n\n-- \nPiotr Krukowiecki\n"},{"id":"164211","messageId":"AANLkTi=7NKn4FrCqFaGH+XTHRw3oLCv=aKPWAJfNsgD_@mail.gmail.com","threadId":"26837","inReplyTo":"AANLkTi=7=QDh0Pe9W4bRcGY5Krg7sBqRcZ2C1YonJSRN@mail.gmail.com","subject":"Re: git cherry improvements suggestions","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-03-24T07:40:39Z","receivedAt":"2011-03-24T07:40:39Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Wed, Mar 23, 2011 at 8:28 PM, Piotr Krukowiecki\n<piotr.krukowiecki@gmail.com> wrote:\n> On Wed, Mar 23, 2011 at 3:44 PM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n>> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 15:43:\n>>> On Wed, Mar 23, 2011 at 2:33 PM, Michael J Gruber\n>>> <git@drmicha.warpmail.net> wrote:\n>>>> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23:\n>>>>> Just some stats:\n>>>>>\n>>>>>    git log --cherry-mark --left-right --oneline --date-order branch...trunk\n>>>>>\n>>>>> lists 1004 commits, takes about 20s and memory peaks to about 670MB\n>>>>> twice during the run (I'm on linux with AMD Phenom II X4 945)\n>>>>>\n>>>>> With limit it prints X last commits (the limiting seems to take place after all\n>>>>> work, on the output list only).\n>>>>>\n>>>>> branch..trunk is 551 commits, the other way is 453 commits.\n>>>>> 710 commits are found to be \"=\", 98 \"<\", 196 \">\".\n>>>>>\n>>>>> Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just\n>>>>> giving real-life stats if anyone was interested.\n>>>>> I suspect such checks won't be done frequently.\n>>>>\n>>>> You don't need to say it's slow - I've said so already :(\n>>>>\n>>>> http://permalink.gmane.org/gmane.comp.version-control.git/169725\n>>>\n>>> In the link above:\n>>>   git cherry A B: 0.4s\n>>>   git rev-list --cherry A...B: 1.7s\n>>>\n>>> So rev-list is 4.25x slower.\n>>>\n>>> In my case it's only 1.23x slower:\n>>>\n>>>    $ time git rev-list --cherry branch...trunk  > /tmp/rev-list\n>>>    real       0m18.627s\n>>>    user       0m17.710s\n>>>    sys        0m0.900s\n>>>\n>>>    $ time git cherry  branch trunk  > /tmp/cherry\n>>>    real       0m15.345s\n>>>    user       0m14.310s\n>>>    sys        0m1.020s\n>>>\n>>>\n>>\n>> How's that with > /dev/null (or with --count for rev-list)? Also, how\n>> many merge bases do you have:\n>>\n>> git merge-base --all branch trunk | wc -l\n>\n> I expect only one - there should be no merges between those two\n> branches.\n>\n> I will do measurements tomorrow.\n\n\nBranches might change a bit since yesterday so the exact numbers\nmight be a bit different.\n\n\n$ time git cherry  branch trunk  > /dev/null\n\nreal\t0m15.246s\nuser\t0m14.260s\nsys\t0m0.970s\n\n\n$ time git rev-list --cherry branch...trunk  > /dev/null\n\nreal\t0m18.801s\nuser\t0m17.980s\nsys\t0m0.800s\n\n\n$ time git rev-list --cherry --count branch...trunk\n556\n\nreal\t0m18.825s\nuser\t0m18.010s\nsys\t0m0.770s\n\n\n$ time git merge-base --all branch trunk  | wc -l\n2\n\nreal\t0m0.538s\nuser\t0m0.490s\nsys\t0m0.040s\n\n\nI expected one merge base, but it appears our history is\nseriously fscked, either by past svn operations or by\ngit-svn clone :)\n\n(I'm not saying there's an error somewhere, just that the\nhistory is ... complicated)\n\n\n-- \nPiotr Krukowiecki\n"},{"id":"164214","messageId":"4D8AF6FF.4080209@drmicha.warpmail.net","threadId":"26837","inReplyTo":"AANLkTi=7NKn4FrCqFaGH+XTHRw3oLCv=aKPWAJfNsgD_@mail.gmail.com","subject":"Re: git cherry improvements suggestions","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-24T07:47:11Z","receivedAt":"2011-03-24T07:47:11Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Piotr Krukowiecki venit, vidit, dixit 24.03.2011 08:40:\n> On Wed, Mar 23, 2011 at 8:28 PM, Piotr Krukowiecki\n> <piotr.krukowiecki@gmail.com> wrote:\n>> On Wed, Mar 23, 2011 at 3:44 PM, Michael J Gruber\n>> <git@drmicha.warpmail.net> wrote:\n>>> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 15:43:\n>>>> On Wed, Mar 23, 2011 at 2:33 PM, Michael J Gruber\n>>>> <git@drmicha.warpmail.net> wrote:\n>>>>> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23:\n>>>>>> Just some stats:\n>>>>>>\n>>>>>>    git log --cherry-mark --left-right --oneline --date-order branch...trunk\n>>>>>>\n>>>>>> lists 1004 commits, takes about 20s and memory peaks to about 670MB\n>>>>>> twice during the run (I'm on linux with AMD Phenom II X4 945)\n>>>>>>\n>>>>>> With limit it prints X last commits (the limiting seems to take place after all\n>>>>>> work, on the output list only).\n>>>>>>\n>>>>>> branch..trunk is 551 commits, the other way is 453 commits.\n>>>>>> 710 commits are found to be \"=\", 98 \"<\", 196 \">\".\n>>>>>>\n>>>>>> Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just\n>>>>>> giving real-life stats if anyone was interested.\n>>>>>> I suspect such checks won't be done frequently.\n>>>>>\n>>>>> You don't need to say it's slow - I've said so already :(\n>>>>>\n>>>>> http://permalink.gmane.org/gmane.comp.version-control.git/169725\n>>>>\n>>>> In the link above:\n>>>>   git cherry A B: 0.4s\n>>>>   git rev-list --cherry A...B: 1.7s\n>>>>\n>>>> So rev-list is 4.25x slower.\n>>>>\n>>>> In my case it's only 1.23x slower:\n>>>>\n>>>>    $ time git rev-list --cherry branch...trunk  > /tmp/rev-list\n>>>>    real       0m18.627s\n>>>>    user       0m17.710s\n>>>>    sys        0m0.900s\n>>>>\n>>>>    $ time git cherry  branch trunk  > /tmp/cherry\n>>>>    real       0m15.345s\n>>>>    user       0m14.310s\n>>>>    sys        0m1.020s\n>>>>\n>>>>\n>>>\n>>> How's that with > /dev/null (or with --count for rev-list)? Also, how\n>>> many merge bases do you have:\n>>>\n>>> git merge-base --all branch trunk | wc -l\n>>\n>> I expect only one - there should be no merges between those two\n>> branches.\n>>\n>> I will do measurements tomorrow.\n> \n> \n> Branches might change a bit since yesterday so the exact numbers\n> might be a bit different.\n> \n> \n> $ time git cherry  branch trunk  > /dev/null\n> \n> real\t0m15.246s\n> user\t0m14.260s\n> sys\t0m0.970s\n> \n> \n> $ time git rev-list --cherry branch...trunk  > /dev/null\n> \n> real\t0m18.801s\n> user\t0m17.980s\n> sys\t0m0.800s\n> \n> \n> $ time git rev-list --cherry --count branch...trunk\n> 556\n> \n> real\t0m18.825s\n> user\t0m18.010s\n> sys\t0m0.770s\n> \n> \n> $ time git merge-base --all branch trunk  | wc -l\n> 2\n> \n> real\t0m0.538s\n> user\t0m0.490s\n> sys\t0m0.040s\n> \n> \n> I expected one merge base, but it appears our history is\n> seriously fscked, either by past svn operations or by\n> git-svn clone :)\n> \n> (I'm not saying there's an error somewhere, just that the\n> history is ... complicated)\n> \n> \n\nThanks for the timings. In your case with only 2 merge bases, the merge\nbase calculation (or rather: simplification) does not make much of a\ndifference, at most 0.5s as we see. I'm still wondering where the rest\nof the 3.5s difference (between cherry and --cherry) is spent, but at\nleast the ratio 18.8/15.2 is more bearable than in my case.\nUnfortunately, this confirms my suspicion that there is more than 1 area\nwhich would need improvement to match cherry's speed.\n\nMichael\n"}]}