Linus Torvalds writes:
> Quite frankly, I suspect it's not worth it, and maybe you just shouldn't
> do that optimization and limit the commits in other ways instead (ie you
> might try to limit them *numerically* instead of by using negative
> commits, and do one first run with the number of commits limited to <n>,
> and then if that wasn't enough to re-connect the trees, you do the whole
> thing)
OK. I have fixed the problem in gitk by making it do:
git rev-list --first-parent --max-count=1 $id -- paths...
for each id that it gets while updating that is a boundary commit, if
we are doing path limiting and the id is one that isn't in the graph.
If what we get back is a commit that is already in the graph, then we
use it instead. That seems to do what I want.
Currently gitk executes that git rev-list synchronously, but if that
causes noticeable pauses, it could be done asynchronously instead.
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
