diff --stat: sometimes use non-linear scaling.

Martin Waitz <taliadmingilde.org> 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 majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Junio C Hamano wrote:
> Martin Waitz <taliadmingilde.org> 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.
> 

Why not just take the stupid and simple solution and make
it:

file1   | +31,-19    +++
file2   | +19,-106   ---
file3   | +10,-10    ###

That is, show the number of lines that actually changed, and
print a 
fixed number of plusses or minuses after the numbers to make
it easy to, 
at a glance, check if more lines were added than deleted or
vice versa.

-- 
Andreas Ericsson                   andreas.ericssonop5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html