Re: [PATCH] rev-list --max-age, --max-count: support --boundary
- From
Junio C Hamano <junkio@cox.net>
- Date
- Feb 19, 2007, 23:40 UTC
- Message-ID
- <7v8xet67j3.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.63.0702190312120.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 14 quoted lines
> Now, when saying --max-age=<timestamp>, or --max-count=<n>, 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 <Johannes.Schindelin@gmx.de> > --- > > 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.
Show 16 quoted lines
> @@ -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.