"Santi Béjar" <sbejar@gmail.com> writes:

quoted text
>  the --topo-order does not play well with --boundary and --max-count.
>
> $ git-rev-list --boundary --max-count=50 5ced0 | wc -l
> 56
> $ git-rev-list --topo-order --boundary --max-count=50 5ced0 | wc -l
> 8846
>
> (5ced0 is git.git's master). I think it should be 56 for both. It
> presents this behaviour since c4025103fa, when was added --boundary
> support for git-rev-list --max-count and --max-age.

I think the code that does --boundary when the list is limited
with --max-count is not quite right, even without topo-order.
Only when the traversal is not limited, the code happens to work
correctly because in that case alone we pick up positive commits
one by one up to the specified count, and do not place anything
other than their immediate parents in the list.

It needs to find out commits (be they marked as UNINTERESTING or
not) still in the revs->commits that are _not_ reachable by any
other commits in the list, or something like that.

I suspect that would unfortunately be very expensive.  Dscho,
have better ideas?


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html