Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 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@xxxxxx>
> ---
>
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html