{"thread":{"id":"6874","subject":"[PATCH] rev-list --max-age, --max-count: support --boundary","startedAt":"2007-02-19T02:14:59Z","lastAt":"2007-02-20T00:27:17Z","messageCount":3,"participants":["Johannes Schindelin","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"34974","messageId":"Pine.LNX.4.63.0702190312120.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6874","inReplyTo":null,"subject":"[PATCH] rev-list --max-age, --max-count: support --boundary","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-19T02:14:59Z","receivedAt":"2007-02-19T02:14:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nNow, when saying --max-age=<timestamp>, or --max-count=<n>, together\nwith --boundary, rev-list prints the boundary commits, i.e. the\ncommits which are _just_ not shown without --boundary, i.e. their\nchildren are, but they aren't.\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n---\n\n\tOf course, this is meant to speed up an otherwise expensive\n\toperation in git-bundle.\n\n\tHowever, this touches a very sensitive point in core git:\n\tthe revision walking machinery. It passes all tests, but\n\tsome eyeballing is much appreciated.\n\n\tAh, and somebody better at writing short concise descriptions\n\tthen me should look into documenting \"edge\" objects and\n\t\"boundary\" commits to the glossary (possibly after thinking\n\tif \"edge\" and \"boundary\" do mean the same after all).\n\n\t'nough for one night.\n\n revision.c |   24 ++++++++++++++++++++----\n 1 files changed, 20 insertions(+), 4 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex 5b1794b..87aea9c 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1233,9 +1233,15 @@ static struct commit *get_revision_1(struct rev_info *revs)\n \t\t */\n \t\tif (!revs->limited) {\n \t\t\tif (revs->max_age != -1 &&\n-\t\t\t    (commit->date < revs->max_age))\n-\t\t\t\tcontinue;\n-\t\t\tadd_parents_to_list(revs, commit, &revs->commits);\n+\t\t\t    (commit->date < revs->max_age)) {\n+\t\t\t\tif (revs->boundary)\n+\t\t\t\t\tcommit->object.flags |=\n+\t\t\t\t\t\tBOUNDARY_SHOW | BOUNDARY;\n+\t\t\t\telse\n+\t\t\t\t\tcontinue;\n+\t\t\t} else\n+\t\t\t\tadd_parents_to_list(revs, commit,\n+\t\t\t\t\t\t&revs->commits);\n \t\t}\n \t\tif (commit->object.flags & SHOWN)\n \t\t\tcontinue;\n@@ -1336,7 +1342,17 @@ struct commit *get_revision(struct rev_info *revs)\n \tcase -1:\n \t\tbreak;\n \tcase 0:\n-\t\treturn NULL;\n+\t\tif (revs->boundary) {\n+\t\t\tstruct commit_list *list = revs->commits;\n+\t\t\twhile (list) {\n+\t\t\t\tlist->item->object.flags |=\n+\t\t\t\t\tBOUNDARY_SHOW | BOUNDARY;\n+\t\t\t\tlist = list->next;\n+\t\t\t}\n+\t\t\trevs->max_count = -1;\n+\t\t\trevs->limited = 1;\n+\t\t} else\n+\t\t\treturn NULL;\n \tdefault:\n \t\trevs->max_count--;\n \t}\n"},{"id":"35044","messageId":"7v8xet67j3.fsf@assigned-by-dhcp.cox.net","threadId":"6874","inReplyTo":"Pine.LNX.4.63.0702190312120.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] rev-list --max-age, --max-count: support --boundary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-19T23:40:16Z","receivedAt":"2007-02-19T23:40:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Now, when saying --max-age=<timestamp>, or --max-count=<n>, together\n> with --boundary, rev-list prints the boundary commits, i.e. the\n> commits which are _just_ not shown without --boundary, i.e. their\n> children are, but they aren't.\n>\n> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n> ---\n>\n> \tOf course, this is meant to speed up an otherwise expensive\n> \toperation in git-bundle.\n>\n> \tHowever, this touches a very sensitive point in core git:\n> \tthe revision walking machinery. It passes all tests, but\n> \tsome eyeballing is much appreciated.\n\nI think this looks fine.\n\nInitially I thought setting BOUNDARY_SHOW unconditionally would\nbe wrong (the \"limited\" case takes pains to avoid showing\nredundant boundary commits), and that was exactly why I said it\nwould be a bit more involved change, but I do not think of a\ntopology that needs redundancy removal outside of \"limited\" case.\n\n> @@ -1336,7 +1342,17 @@ struct commit *get_revision(struct rev_info *revs)\n>  \tcase -1:\n>  \t\tbreak;\n>  \tcase 0:\n> -\t\treturn NULL;\n> +\t\tif (revs->boundary) {\n> +\t\t\tstruct commit_list *list = revs->commits;\n> +\t\t\twhile (list) {\n> +\t\t\t\tlist->item->object.flags |=\n> +\t\t\t\t\tBOUNDARY_SHOW | BOUNDARY;\n> +\t\t\t\tlist = list->next;\n> +\t\t\t}\n> +\t\t\trevs->max_count = -1;\n> +\t\t\trevs->limited = 1;\n> +\t\t} else\n> +\t\t\treturn NULL;\n\nThe resetting of max_count and limited probably needs some\ncommenting.\n"},{"id":"35055","messageId":"Pine.LNX.4.63.0702200126180.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6874","inReplyTo":"7v8xet67j3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] rev-list --max-age, --max-count: support --boundary","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-20T00:27:17Z","receivedAt":"2007-02-20T00:27:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 19 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > @@ -1336,7 +1342,17 @@ struct commit *get_revision(struct rev_info *revs)\n> >  \tcase -1:\n> >  \t\tbreak;\n> >  \tcase 0:\n> > -\t\treturn NULL;\n> > +\t\tif (revs->boundary) {\n> > +\t\t\tstruct commit_list *list = revs->commits;\n> > +\t\t\twhile (list) {\n> > +\t\t\t\tlist->item->object.flags |=\n> > +\t\t\t\t\tBOUNDARY_SHOW | BOUNDARY;\n> > +\t\t\t\tlist = list->next;\n> > +\t\t\t}\n> > +\t\t\trevs->max_count = -1;\n> > +\t\t\trevs->limited = 1;\n> > +\t\t} else\n> > +\t\t\treturn NULL;\n> \n> The resetting of max_count and limited probably needs some\n> commenting.\n\nRight. Could you --amend with this, if you find it sufficient?\n\n---\n\n revision.c |    1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex 87aea9c..be57191 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1349,6 +1349,7 @@ struct commit *get_revision(struct rev_info *revs)\n \t\t\t\t\tBOUNDARY_SHOW | BOUNDARY;\n \t\t\t\tlist = list->next;\n \t\t\t}\n+\t\t\t/* all remaining commits are boundary commits */\n \t\t\trevs->max_count = -1;\n \t\t\trevs->limited = 1;\n \t\t} else\n"}]}