* git cherry improvements suggestions
@ 2011-03-23 8:11 Piotr Krukowiecki
2011-03-23 10:46 ` Michael J Gruber
0 siblings, 1 reply; 9+ messages in thread
From: Piotr Krukowiecki @ 2011-03-23 8:11 UTC (permalink / raw)
To: Git Mailing List
Hi,
Short version:
1. The <limit> is misleading IMO
2. Please extend the output to show "full diff"
3. Please add numerical/time <limit>
4. Would it be possible to use "=" for "equivalent change"?
Please tell me your opinions.
Long version:
I have a branch that have diverged long time ago from main branch. I can't use
merge, so I'm using cherry-pick to transplant changes between branches
(the other reason is I'm using git-svn...)
I noticed I did not transplant a certain commit recently. I wanted to
see if there
are any other commits I didn't transplant. I tried using git cherry:
1. man page says: git cherry [-v] [<upstream> [<head> [<limit>]]]
$ git cherry -v master 9_1 20
fatal: Unknown commit 20
After reading man page I though the limit is a numeric limit, like "check
last 20 commits".
I just realized it is a commit sha1. I think man could be improved to explicitly
say it's sha1 - maybe change the name from <limit> to something else
(<sha1>? <sha1_limit>?)
2. The cherry currently shows only changes against one branch:
Every commit that doesn’t exist in the <upstream> branch has its id (sha1)
reported[...] The ones that have equivalent change already in the <upstream>
branch are prefixed with a minus (-) sign, and those that only exist in the
<head> branch are prefixed with a plus (+) symbol
So it will not show commits that exist only in <upstream> but not in <head>.
In my case changes are transplanted both ways (in general), so I have to check
both branches.
I understand I can switch branch positions, but this requires post-processing
to get rid of equivalent commits, maybe something like this:.
git cherry upstream head | grep '^[+]' > head_only
git cherry head upstream | grep '^[+]' > upstream_only
This is not very convenient, and I think you won't be able to see transplanted
changes with different ids (e.g. with conflicts) next to each other (such
commits would have probably the same commit message and it's possible
they were done at the same/close time, so it should be easy to see that
although the commits are shown as different, they represent the same change)
I think it would be usable to be able to see all changes:
- commits in upstream only
- commits in head only
- equivalent commits (in both upstream and head)
Not sure how it should act in case of <limit> - maybe it should be illegal
to use <limit> in this mode. See also next point.
3. I think a numerical limit (or even: time limit etc) of checked commits would
be useful, especially in "full diff" mode. Without it would be not
possible to do a
full diff with a limit, and when switching branch positions you'd have to lookup
two commits:
<find commit on head>
git cherry upstream head head_limit | grep '^[+]' > head_only
<find commit on upstream>
git cherry head upstream upstream_limit | grep '^[+]' > upstream_only
In case of numerical <limit> it should probably take <limit> changes
from head and
<limit> changes from upstream and see what is their status. So the actual
output would list from <limit> to 2*<limit> commits depending if all
commits are on
both branches, or no commit is equal.
4. The output format uses "-" to show commits that exist in both branches.
I find this unnatural. There probably is a reason for this? But maybe it would
be possible to change the symbols? For example:
- commit in upstream only
+ commit in head only
= equivalent commit
Or "<", ">", " " or any other graphic symbol.
Thanks for you time reading this long post :)
--
Piotr Krukowiecki
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: git cherry improvements suggestions 2011-03-23 8:11 git cherry improvements suggestions Piotr Krukowiecki @ 2011-03-23 10:46 ` Michael J Gruber 2011-03-23 13:23 ` Piotr Krukowiecki 0 siblings, 1 reply; 9+ messages in thread From: Michael J Gruber @ 2011-03-23 10:46 UTC (permalink / raw) To: Piotr Krukowiecki; +Cc: Git Mailing List Piotr Krukowiecki venit, vidit, dixit 23.03.2011 09:11: > Hi, > > Short version: > > 1. The <limit> is misleading IMO In what way? Is the documentation wrong? > 2. Please extend the output to show "full diff" > 3. Please add numerical/time <limit> > 4. Would it be possible to use "=" for "equivalent change"? > > Please tell me your opinions. You will be a happy user of "git log --cherry A...B" instead of "git cherry A B". It gives you all the log option (e.g. p for diff) that you like and uses "=" rather than "-". It's currently in next and will be in the next release. > > > Long version: > > I have a branch that have diverged long time ago from main branch. I can't use > merge, so I'm using cherry-pick to transplant changes between branches > (the other reason is I'm using git-svn...) > > I noticed I did not transplant a certain commit recently. I wanted to > see if there > are any other commits I didn't transplant. I tried using git cherry: > > > 1. man page says: git cherry [-v] [<upstream> [<head> [<limit>]]] > > $ git cherry -v master 9_1 20 > fatal: Unknown commit 20 > > After reading man page I though the limit is a numeric limit, like "check > last 20 commits". It clearly is the name of a commit in that picture. > > 2. The cherry currently shows only changes against one branch: > > Every commit that doesn’t exist in the <upstream> branch has its id (sha1) > reported[...] The ones that have equivalent change already in the <upstream> > branch are prefixed with a minus (-) sign, and those that only exist in the > <head> branch are prefixed with a plus (+) symbol > > So it will not show commits that exist only in <upstream> but not in <head>. > > In my case changes are transplanted both ways (in general), so I have to check > both branches. You'll be a happy user of "git log --cherry-mark --left-right A...B" :) > 3. I think a numerical limit (or even: time limit etc) of checked commits would > be useful, especially in "full diff" mode. Without it would be not log has a limit argument (-<number>), though I'm not sure it is exactly what you want. > 4. The output format uses "-" to show commits that exist in both branches. > I find this unnatural. There probably is a reason for this? But maybe it would > be possible to change the symbols? For example: > > - commit in upstream only > + commit in head only > = equivalent commit > > Or "<", ">", " " or any other graphic symbol. git log --cherry-mark --left-right will use <,=,> git log --cherry-mark or --cherry will use *,= (And yes, you can use it with --graph!) Cheers, Michael ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git cherry improvements suggestions 2011-03-23 10:46 ` Michael J Gruber @ 2011-03-23 13:23 ` Piotr Krukowiecki 2011-03-23 13:33 ` Michael J Gruber 0 siblings, 1 reply; 9+ messages in thread From: Piotr Krukowiecki @ 2011-03-23 13:23 UTC (permalink / raw) To: Michael J Gruber; +Cc: Git Mailing List On Wed, Mar 23, 2011 at 11:46 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote: > Piotr Krukowiecki venit, vidit, dixit 23.03.2011 09:11: >> Hi, >> >> Short version: >> >> 1. The <limit> is misleading IMO > > In what way? Is the documentation wrong? No, but for me <limit> looks like numeric limit. There is no explicit note in man page that it's a commit. >> 2. Please extend the output to show "full diff" >> 3. Please add numerical/time <limit> >> 4. Would it be possible to use "=" for "equivalent change"? >> >> Please tell me your opinions. > > You will be a happy user of "git log --cherry A...B" instead of "git > cherry A B". It gives you all the log option (e.g. p for diff) that you > like and uses "=" rather than "-". It's currently in next and will be in > the next release. I've tried it and indeed I'm happy! :) The "git log --cherry-mark --left-right A...B" is what I needed! Just some stats: git log --cherry-mark --left-right --oneline --date-order branch...trunk lists 1004 commits, takes about 20s and memory peaks to about 670MB twice during the run (I'm on linux with AMD Phenom II X4 945) With limit it prints X last commits (the limiting seems to take place after all work, on the output list only). branch..trunk is 551 commits, the other way is 453 commits. 710 commits are found to be "=", 98 "<", 196 ">". Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just giving real-life stats if anyone was interested. I suspect such checks won't be done frequently. So thanks for the great improvement! >> 1. man page says: git cherry [-v] [<upstream> [<head> [<limit>]]] >> >> $ git cherry -v master 9_1 20 >> fatal: Unknown commit 20 >> >> After reading man page I though the limit is a numeric limit, like "check >> last 20 commits". > > It clearly is the name of a commit in that picture. I have assumed the limit is numerical and means number of commits. Coming from that assumption it looked like cherry used the limit number as a commit by mistake. >> 2. The cherry currently shows only changes against one branch: >> >> Every commit that doesn’t exist in the <upstream> branch has its id (sha1) >> reported[...] The ones that have equivalent change already in the <upstream> >> branch are prefixed with a minus (-) sign, and those that only exist in the >> <head> branch are prefixed with a plus (+) symbol >> >> So it will not show commits that exist only in <upstream> but not in <head>. >> >> In my case changes are transplanted both ways (in general), so I have to check >> both branches. > > You'll be a happy user of "git log --cherry-mark --left-right A...B" :) Thanks again :) >> 3. I think a numerical limit (or even: time limit etc) of checked commits would >> be useful, especially in "full diff" mode. Without it would be not > > log has a limit argument (-<number>), though I'm not sure it is exactly > what you want. I'd be happy if the limiting was done before all the work, so the performance could be improved by that. For example, it could take <number> last commits from each branch and check only them. This would help if you wanted to check only last week commits. >> 4. The output format uses "-" to show commits that exist in both branches. >> I find this unnatural. There probably is a reason for this? But maybe it would >> be possible to change the symbols? For example: >> >> - commit in upstream only >> + commit in head only >> = equivalent commit >> >> Or "<", ">", " " or any other graphic symbol. > > git log --cherry-mark --left-right will use <,=,> > git log --cherry-mark or --cherry will use *,= > > (And yes, you can use it with --graph!) I've done some quick tests to see how --cherry works, maybe someone will find them useful: # setup $ echo a > a && git add a && git commit -a -m a $ echo b > b && git add b && git commit -a -m b $ echo a1 > a && git add a1 && git commit -a -m a1 $ echo a1 > a && git add a && git commit -a -m a1 $ git checkout -b topic HEAD^ $ echo b1 > b && git add b && git commit -a -m b1 $ echo c > c && git add c && git commit -a -m c $ git checkout master $ echo d > d && git add d && git commit -a -m d # cherry pick a1 into topic and b1 into master $ git log --oneline --graph topic master * b1f200c a1 * 6b95eb4 c * ab34325 b1 | * 15ff34f b1 | * d78c15d d | * ace8ef2 a1 |/ * 9d88558 b * bd17dd4 a $ git log --oneline --cherry topic...master = 15ff34f b1 + d78c15d d = ace8ef2 a1 $ git log --oneline --cherry master...topic = b1f200c a1 + 6b95eb4 c = ab34325 b1 $ git log --oneline --cherry -2 topic...master = 15ff34f b1 + d78c15d d $ git log --oneline --cherry -2 master...topic = b1f200c a1 + 6b95eb4 c $ git cherry topic master - ace8ef21d85b060b98d3f7d8a3b3753ee9b98317 + d78c15df0ee457f77dab7b0b247735dfec246b65 - 15ff34f8a342b6e8999d0e5d528e0b8875fb8042 $ git cherry master topic - ab343256684621d5bc68084f1d77f1b8312b6a3b + 6b95eb4c01647de623f478219eb932b07b97edc6 - b1f200c49c562517eafd77872bf5394960eee53f -- Piotr Krukowiecki ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git cherry improvements suggestions 2011-03-23 13:23 ` Piotr Krukowiecki @ 2011-03-23 13:33 ` Michael J Gruber 2011-03-23 14:43 ` Piotr Krukowiecki 0 siblings, 1 reply; 9+ messages in thread From: Michael J Gruber @ 2011-03-23 13:33 UTC (permalink / raw) To: Piotr Krukowiecki; +Cc: Git Mailing List Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23: > On Wed, Mar 23, 2011 at 11:46 AM, Michael J Gruber > <git@drmicha.warpmail.net> wrote: ... >> You will be a happy user of "git log --cherry A...B" instead of "git >> cherry A B". It gives you all the log option (e.g. p for diff) that you >> like and uses "=" rather than "-". It's currently in next and will be in >> the next release. > > I've tried it and indeed I'm happy! :) > The "git log --cherry-mark --left-right A...B" is what I needed! > > Just some stats: > > git log --cherry-mark --left-right --oneline --date-order branch...trunk > > lists 1004 commits, takes about 20s and memory peaks to about 670MB > twice during the run (I'm on linux with AMD Phenom II X4 945) > > With limit it prints X last commits (the limiting seems to take place after all > work, on the output list only). > > branch..trunk is 551 commits, the other way is 453 commits. > 710 commits are found to be "=", 98 "<", 196 ">". > > Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just > giving real-life stats if anyone was interested. > I suspect such checks won't be done frequently. You don't need to say it's slow - I've said so already :( http://permalink.gmane.org/gmane.comp.version-control.git/169725 But I hope we can remove some bottle-necks. > So thanks for the great improvement! You're welcome :) Michael ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git cherry improvements suggestions 2011-03-23 13:33 ` Michael J Gruber @ 2011-03-23 14:43 ` Piotr Krukowiecki 2011-03-23 14:44 ` Michael J Gruber 0 siblings, 1 reply; 9+ messages in thread From: Piotr Krukowiecki @ 2011-03-23 14:43 UTC (permalink / raw) To: Michael J Gruber; +Cc: Git Mailing List On Wed, Mar 23, 2011 at 2:33 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote: > Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23: >> Just some stats: >> >> git log --cherry-mark --left-right --oneline --date-order branch...trunk >> >> lists 1004 commits, takes about 20s and memory peaks to about 670MB >> twice during the run (I'm on linux with AMD Phenom II X4 945) >> >> With limit it prints X last commits (the limiting seems to take place after all >> work, on the output list only). >> >> branch..trunk is 551 commits, the other way is 453 commits. >> 710 commits are found to be "=", 98 "<", 196 ">". >> >> Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just >> giving real-life stats if anyone was interested. >> I suspect such checks won't be done frequently. > > You don't need to say it's slow - I've said so already :( > > http://permalink.gmane.org/gmane.comp.version-control.git/169725 In the link above: git cherry A B: 0.4s git rev-list --cherry A...B: 1.7s So rev-list is 4.25x slower. In my case it's only 1.23x slower: $ time git rev-list --cherry branch...trunk > /tmp/rev-list real 0m18.627s user 0m17.710s sys 0m0.900s $ time git cherry branch trunk > /tmp/cherry real 0m15.345s user 0m14.310s sys 0m1.020s -- Piotr Krukowiecki ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git cherry improvements suggestions 2011-03-23 14:43 ` Piotr Krukowiecki @ 2011-03-23 14:44 ` Michael J Gruber 2011-03-23 19:28 ` Piotr Krukowiecki 0 siblings, 1 reply; 9+ messages in thread From: Michael J Gruber @ 2011-03-23 14:44 UTC (permalink / raw) To: Piotr Krukowiecki; +Cc: Git Mailing List Piotr Krukowiecki venit, vidit, dixit 23.03.2011 15:43: > On Wed, Mar 23, 2011 at 2:33 PM, Michael J Gruber > <git@drmicha.warpmail.net> wrote: >> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23: >>> Just some stats: >>> >>> git log --cherry-mark --left-right --oneline --date-order branch...trunk >>> >>> lists 1004 commits, takes about 20s and memory peaks to about 670MB >>> twice during the run (I'm on linux with AMD Phenom II X4 945) >>> >>> With limit it prints X last commits (the limiting seems to take place after all >>> work, on the output list only). >>> >>> branch..trunk is 551 commits, the other way is 453 commits. >>> 710 commits are found to be "=", 98 "<", 196 ">". >>> >>> Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just >>> giving real-life stats if anyone was interested. >>> I suspect such checks won't be done frequently. >> >> You don't need to say it's slow - I've said so already :( >> >> http://permalink.gmane.org/gmane.comp.version-control.git/169725 > > In the link above: > git cherry A B: 0.4s > git rev-list --cherry A...B: 1.7s > > So rev-list is 4.25x slower. > > In my case it's only 1.23x slower: > > $ time git rev-list --cherry branch...trunk > /tmp/rev-list > real 0m18.627s > user 0m17.710s > sys 0m0.900s > > $ time git cherry branch trunk > /tmp/cherry > real 0m15.345s > user 0m14.310s > sys 0m1.020s > > How's that with > /dev/null (or with --count for rev-list)? Also, how many merge bases do you have: git merge-base --all branch trunk | wc -l Thanks! Michael ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git cherry improvements suggestions 2011-03-23 14:44 ` Michael J Gruber @ 2011-03-23 19:28 ` Piotr Krukowiecki 2011-03-24 7:40 ` Piotr Krukowiecki 0 siblings, 1 reply; 9+ messages in thread From: Piotr Krukowiecki @ 2011-03-23 19:28 UTC (permalink / raw) To: Michael J Gruber; +Cc: Git Mailing List On Wed, Mar 23, 2011 at 3:44 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote: > Piotr Krukowiecki venit, vidit, dixit 23.03.2011 15:43: >> On Wed, Mar 23, 2011 at 2:33 PM, Michael J Gruber >> <git@drmicha.warpmail.net> wrote: >>> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23: >>>> Just some stats: >>>> >>>> git log --cherry-mark --left-right --oneline --date-order branch...trunk >>>> >>>> lists 1004 commits, takes about 20s and memory peaks to about 670MB >>>> twice during the run (I'm on linux with AMD Phenom II X4 945) >>>> >>>> With limit it prints X last commits (the limiting seems to take place after all >>>> work, on the output list only). >>>> >>>> branch..trunk is 551 commits, the other way is 453 commits. >>>> 710 commits are found to be "=", 98 "<", 196 ">". >>>> >>>> Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just >>>> giving real-life stats if anyone was interested. >>>> I suspect such checks won't be done frequently. >>> >>> You don't need to say it's slow - I've said so already :( >>> >>> http://permalink.gmane.org/gmane.comp.version-control.git/169725 >> >> In the link above: >> git cherry A B: 0.4s >> git rev-list --cherry A...B: 1.7s >> >> So rev-list is 4.25x slower. >> >> In my case it's only 1.23x slower: >> >> $ time git rev-list --cherry branch...trunk > /tmp/rev-list >> real 0m18.627s >> user 0m17.710s >> sys 0m0.900s >> >> $ time git cherry branch trunk > /tmp/cherry >> real 0m15.345s >> user 0m14.310s >> sys 0m1.020s >> >> > > How's that with > /dev/null (or with --count for rev-list)? Also, how > many merge bases do you have: > > git merge-base --all branch trunk | wc -l I expect only one - there should be no merges between those two branches. I will do measurements tomorrow. -- Piotr Krukowiecki ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git cherry improvements suggestions 2011-03-23 19:28 ` Piotr Krukowiecki @ 2011-03-24 7:40 ` Piotr Krukowiecki 2011-03-24 7:47 ` Michael J Gruber 0 siblings, 1 reply; 9+ messages in thread From: Piotr Krukowiecki @ 2011-03-24 7:40 UTC (permalink / raw) To: Michael J Gruber; +Cc: Git Mailing List On Wed, Mar 23, 2011 at 8:28 PM, Piotr Krukowiecki <piotr.krukowiecki@gmail.com> wrote: > On Wed, Mar 23, 2011 at 3:44 PM, Michael J Gruber > <git@drmicha.warpmail.net> wrote: >> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 15:43: >>> On Wed, Mar 23, 2011 at 2:33 PM, Michael J Gruber >>> <git@drmicha.warpmail.net> wrote: >>>> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23: >>>>> Just some stats: >>>>> >>>>> git log --cherry-mark --left-right --oneline --date-order branch...trunk >>>>> >>>>> lists 1004 commits, takes about 20s and memory peaks to about 670MB >>>>> twice during the run (I'm on linux with AMD Phenom II X4 945) >>>>> >>>>> With limit it prints X last commits (the limiting seems to take place after all >>>>> work, on the output list only). >>>>> >>>>> branch..trunk is 551 commits, the other way is 453 commits. >>>>> 710 commits are found to be "=", 98 "<", 196 ">". >>>>> >>>>> Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just >>>>> giving real-life stats if anyone was interested. >>>>> I suspect such checks won't be done frequently. >>>> >>>> You don't need to say it's slow - I've said so already :( >>>> >>>> http://permalink.gmane.org/gmane.comp.version-control.git/169725 >>> >>> In the link above: >>> git cherry A B: 0.4s >>> git rev-list --cherry A...B: 1.7s >>> >>> So rev-list is 4.25x slower. >>> >>> In my case it's only 1.23x slower: >>> >>> $ time git rev-list --cherry branch...trunk > /tmp/rev-list >>> real 0m18.627s >>> user 0m17.710s >>> sys 0m0.900s >>> >>> $ time git cherry branch trunk > /tmp/cherry >>> real 0m15.345s >>> user 0m14.310s >>> sys 0m1.020s >>> >>> >> >> How's that with > /dev/null (or with --count for rev-list)? Also, how >> many merge bases do you have: >> >> git merge-base --all branch trunk | wc -l > > I expect only one - there should be no merges between those two > branches. > > I will do measurements tomorrow. Branches might change a bit since yesterday so the exact numbers might be a bit different. $ time git cherry branch trunk > /dev/null real 0m15.246s user 0m14.260s sys 0m0.970s $ time git rev-list --cherry branch...trunk > /dev/null real 0m18.801s user 0m17.980s sys 0m0.800s $ time git rev-list --cherry --count branch...trunk 556 real 0m18.825s user 0m18.010s sys 0m0.770s $ time git merge-base --all branch trunk | wc -l 2 real 0m0.538s user 0m0.490s sys 0m0.040s I expected one merge base, but it appears our history is seriously fscked, either by past svn operations or by git-svn clone :) (I'm not saying there's an error somewhere, just that the history is ... complicated) -- Piotr Krukowiecki ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git cherry improvements suggestions 2011-03-24 7:40 ` Piotr Krukowiecki @ 2011-03-24 7:47 ` Michael J Gruber 0 siblings, 0 replies; 9+ messages in thread From: Michael J Gruber @ 2011-03-24 7:47 UTC (permalink / raw) To: Piotr Krukowiecki; +Cc: Git Mailing List Piotr Krukowiecki venit, vidit, dixit 24.03.2011 08:40: > On Wed, Mar 23, 2011 at 8:28 PM, Piotr Krukowiecki > <piotr.krukowiecki@gmail.com> wrote: >> On Wed, Mar 23, 2011 at 3:44 PM, Michael J Gruber >> <git@drmicha.warpmail.net> wrote: >>> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 15:43: >>>> On Wed, Mar 23, 2011 at 2:33 PM, Michael J Gruber >>>> <git@drmicha.warpmail.net> wrote: >>>>> Piotr Krukowiecki venit, vidit, dixit 23.03.2011 14:23: >>>>>> Just some stats: >>>>>> >>>>>> git log --cherry-mark --left-right --oneline --date-order branch...trunk >>>>>> >>>>>> lists 1004 commits, takes about 20s and memory peaks to about 670MB >>>>>> twice during the run (I'm on linux with AMD Phenom II X4 945) >>>>>> >>>>>> With limit it prints X last commits (the limiting seems to take place after all >>>>>> work, on the output list only). >>>>>> >>>>>> branch..trunk is 551 commits, the other way is 453 commits. >>>>>> 710 commits are found to be "=", 98 "<", 196 ">". >>>>>> >>>>>> Note, I'm not saying it's too slow, or that it's working incorrectly, I'm just >>>>>> giving real-life stats if anyone was interested. >>>>>> I suspect such checks won't be done frequently. >>>>> >>>>> You don't need to say it's slow - I've said so already :( >>>>> >>>>> http://permalink.gmane.org/gmane.comp.version-control.git/169725 >>>> >>>> In the link above: >>>> git cherry A B: 0.4s >>>> git rev-list --cherry A...B: 1.7s >>>> >>>> So rev-list is 4.25x slower. >>>> >>>> In my case it's only 1.23x slower: >>>> >>>> $ time git rev-list --cherry branch...trunk > /tmp/rev-list >>>> real 0m18.627s >>>> user 0m17.710s >>>> sys 0m0.900s >>>> >>>> $ time git cherry branch trunk > /tmp/cherry >>>> real 0m15.345s >>>> user 0m14.310s >>>> sys 0m1.020s >>>> >>>> >>> >>> How's that with > /dev/null (or with --count for rev-list)? Also, how >>> many merge bases do you have: >>> >>> git merge-base --all branch trunk | wc -l >> >> I expect only one - there should be no merges between those two >> branches. >> >> I will do measurements tomorrow. > > > Branches might change a bit since yesterday so the exact numbers > might be a bit different. > > > $ time git cherry branch trunk > /dev/null > > real 0m15.246s > user 0m14.260s > sys 0m0.970s > > > $ time git rev-list --cherry branch...trunk > /dev/null > > real 0m18.801s > user 0m17.980s > sys 0m0.800s > > > $ time git rev-list --cherry --count branch...trunk > 556 > > real 0m18.825s > user 0m18.010s > sys 0m0.770s > > > $ time git merge-base --all branch trunk | wc -l > 2 > > real 0m0.538s > user 0m0.490s > sys 0m0.040s > > > I expected one merge base, but it appears our history is > seriously fscked, either by past svn operations or by > git-svn clone :) > > (I'm not saying there's an error somewhere, just that the > history is ... complicated) > > Thanks for the timings. In your case with only 2 merge bases, the merge base calculation (or rather: simplification) does not make much of a difference, at most 0.5s as we see. I'm still wondering where the rest of the 3.5s difference (between cherry and --cherry) is spent, but at least the ratio 18.8/15.2 is more bearable than in my case. Unfortunately, this confirms my suspicion that there is more than 1 area which would need improvement to match cherry's speed. Michael ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-03-24 7:50 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-03-23 8:11 git cherry improvements suggestions Piotr Krukowiecki 2011-03-23 10:46 ` Michael J Gruber 2011-03-23 13:23 ` Piotr Krukowiecki 2011-03-23 13:33 ` Michael J Gruber 2011-03-23 14:43 ` Piotr Krukowiecki 2011-03-23 14:44 ` Michael J Gruber 2011-03-23 19:28 ` Piotr Krukowiecki 2011-03-24 7:40 ` Piotr Krukowiecki 2011-03-24 7:47 ` Michael J Gruber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).