On Sun, Sep 11, 2011 at 03:56:39PM +0300, Daniel Shahaf wrote: > I floated on IRC the idea of having the output not try filter out > inoperative revisions.
That would not completey fix the problem. In the case we're looking at there is one huge gap in the range of revisions already merged. So, yes, the output would be short if we collapsed inoperative revisions -- we'd just print a single range. However, what if I want to reintegrate a long-lived branch in which every other revision was a cherry-pick merge from trunk? In this case, the missing revisions are N, N+2, N+4, ... which cannot be combined into a single range. This is a contrived case, of course. But I'd prefer a solution that cannot cause such problems under any circumstances. We shouldn't try to keep a list of unknown and potentially massive size in memory. So putting this list into an error message is wrong. At the very least, we should pass off ranges to a client-provided callback as we receive them from the server. Then the client can print each range and the range can be freed immediately before the server sends the next one. But, again, I don't see how printing a precise, but massive, list of missing revisions helps users. The time spent downloading and displaying all this information could be better spent if we told users "there are one or more missing ranges, please run a sync merge from trunk first, and try again."
