# [PATCH] rev-list --max-age, --max-count: support --boundary 3 messages from 2007-02-19 to 2007-02-20. Participants: Johannes Schindelin, Junio C Hamano. Thread: https://gitlist.dev/t/6874 ## Johannes Schindelin, 2007-02-19 02:14 Subject: [PATCH] rev-list --max-age, --max-count: support --boundary Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0702190312120.22628%40wbgn013.biozentrum.uni-wuerzburg.de ``` Now, when saying --max-age=, or --max-count=, together with --boundary, rev-list prints the boundary commits, i.e. the commits which are _just_ not shown without --boundary, i.e. their children are, but they aren't. Signed-off-by: Johannes Schindelin --- Of course, this is meant to speed up an otherwise expensive operation in git-bundle. However, this touches a very sensitive point in core git: the revision walking machinery. It passes all tests, but some eyeballing is much appreciated. Ah, and somebody better at writing short concise descriptions then me should look into documenting "edge" objects and "boundary" commits to the glossary (possibly after thinking if "edge" and "boundary" do mean the same after all). 'nough for one night. revision.c | 24 ++++++++++++++++++++---- 1 files changed, 20 insertions(+), 4 deletions(-) diff --git a/revision.c b/revision.c index 5b1794b..87aea9c 100644 --- a/revision.c +++ b/revision.c @@ -1233,9 +1233,15 @@ static struct commit *get_revision_1(struct rev_info *revs) */ if (!revs->limited) { if (revs->max_age != -1 && - (commit->date < revs->max_age)) - continue; - add_parents_to_list(revs, commit, &revs->commits); + (commit->date < revs->max_age)) { + if (revs->boundary) + commit->object.flags |= + BOUNDARY_SHOW | BOUNDARY; + else + continue; + } else + add_parents_to_list(revs, commit, + &revs->commits); } if (commit->object.flags & SHOWN) continue; @@ -1336,7 +1342,17 @@ struct commit *get_revision(struct rev_info *revs) case -1: break; case 0: - return NULL; + if (revs->boundary) { + struct commit_list *list = revs->commits; + while (list) { + list->item->object.flags |= + BOUNDARY_SHOW | BOUNDARY; + list = list->next; + } + revs->max_count = -1; + revs->limited = 1; + } else + return NULL; default: revs->max_count--; } ``` ## Junio C Hamano, 2007-02-19 23:40 Subject: Re: [PATCH] rev-list --max-age, --max-count: support --boundary Message-ID: <7v8xet67j3.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v8xet67j3.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Johannes Schindelin writes: > Now, when saying --max-age=, or --max-count=, together > with --boundary, rev-list prints the boundary commits, i.e. the > commits which are _just_ not shown without --boundary, i.e. their > children are, but they aren't. > > Signed-off-by: Johannes Schindelin > --- > > Of course, this is meant to speed up an otherwise expensive > operation in git-bundle. > > However, this touches a very sensitive point in core git: > the revision walking machinery. It passes all tests, but > some eyeballing is much appreciated. I think this looks fine. Initially I thought setting BOUNDARY_SHOW unconditionally would be wrong (the "limited" case takes pains to avoid showing redundant boundary commits), and that was exactly why I said it would be a bit more involved change, but I do not think of a topology that needs redundancy removal outside of "limited" case. > @@ -1336,7 +1342,17 @@ struct commit *get_revision(struct rev_info *revs) > case -1: > break; > case 0: > - return NULL; > + if (revs->boundary) { > + struct commit_list *list = revs->commits; > + while (list) { > + list->item->object.flags |= > + BOUNDARY_SHOW | BOUNDARY; > + list = list->next; > + } > + revs->max_count = -1; > + revs->limited = 1; > + } else > + return NULL; The resetting of max_count and limited probably needs some commenting. ``` ## Johannes Schindelin, 2007-02-20 00:27 Subject: Re: [PATCH] rev-list --max-age, --max-count: support --boundary Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0702200126180.22628%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7v8xet67j3.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Mon, 19 Feb 2007, Junio C Hamano wrote: > Johannes Schindelin writes: > > > @@ -1336,7 +1342,17 @@ struct commit *get_revision(struct rev_info *revs) > > case -1: > > break; > > case 0: > > - return NULL; > > + if (revs->boundary) { > > + struct commit_list *list = revs->commits; > > + while (list) { > > + list->item->object.flags |= > > + BOUNDARY_SHOW | BOUNDARY; > > + list = list->next; > > + } > > + revs->max_count = -1; > > + revs->limited = 1; > > + } else > > + return NULL; > > The resetting of max_count and limited probably needs some > commenting. Right. Could you --amend with this, if you find it sufficient? --- revision.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/revision.c b/revision.c index 87aea9c..be57191 100644 --- a/revision.c +++ b/revision.c @@ -1349,6 +1349,7 @@ struct commit *get_revision(struct rev_info *revs) BOUNDARY_SHOW | BOUNDARY; list = list->next; } + /* all remaining commits are boundary commits */ revs->max_count = -1; revs->limited = 1; } else ```