Paul Mackerras <paulus@xxxxxxxxx> writes: > If git log had an argument to tell it to mark those commits that were > a starting point or a finishing point, then I could simplify this > logic enormously, plus we wouldn't have to pass a long parameter list > to git log. It may still turn out to be necessary to add a negative > argument for each previous starting point, though, when refreshing the > list. > > I think the simplest fix for now is to arrange to take the > non-optimized path on windows when the list of revs gets too long, > i.e., set $vcanopt($view) to 0 and take that path. That means that > refreshing the view will be slow, but I think it's the best we can do > at this point. Hmph. The negative ones you can learn by giving --boundary, but I do not think the set of starting points are something you can get out of log output. Even if you could, you would have the same issue giving them from the command line anyway. The right solution would likely to be to give the same --stdin option as rev-list to "git log", I think. -- 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