Martin Waitz <tali@xxxxxxxxxxxxxx> writes: >> It should at least never be superlinear, I believe. > > So if we want to keep the logarithmic scale we can do some maths: >... > But only I have not succeeded in solving these equations, I always stop > at the last invariant :-( There is another constraint you did not mention. Here is the output from my another failed experiment: .gitignore | 1 - Documentation/git-tar-tree.txt | 3 +++ Documentation/git-upload-tar.txt | 39 ----------------------------- Documentation/git.txt | 4 ---- Makefile | 1 - builtin-tar-tree.c | 130 +++++++++++++++----------------------- builtin-upload-tar.c | 74 ---------------------------------- git.c | 1 - 8 files changed, 53 insertions(+), 200 deletions(-) The deletion from Documentation/git-upload-tar.txt looks much larger than addition to builtin-tar-tree.c in the above, but there are 50 lines added to builtin-tar-tree.c (which is why this experiment is a failure). Because we are dealing with non-linear scaling, the total of scaled adds and scaled deletes does not equal to scaled total. We can deal with this in two ways. Scale the total and distribute it, or scale adds and deletes individually and make sure the sum of scaled adds and deletes never exceed the width. Obviously the former is easier to implement but it was _wrong_. The fitting algorithm in the posted patch scales the total to fit the alloted width and then distributes the result to adds and deletes. - 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