Junio C Hamano writes: > 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. A --stdin option to git log would be great, but it doesn't seem to be implemented yet. How hard would it be to add? Paul. -- 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