Re: [BUG] git-rev-list: --topo-order --boundary and --max-count
- From
Junio C Hamano <junkio@cox.net>
- Date
- Mar 5, 2007, 10:39 UTC
- Message-ID
- <7vlkicynwm.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <8aa486160703050202y5ee159d2i42a2859a00b41679@mail.gmail.com>
"Santi Béjar" <sbejar@gmail.com> writes:
Show 10 quoted lines
> 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?