From: Rogan Dawes <discard@dawes.za.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Show binary file size change in diff --stat
Date: Thu, 01 Mar 2007 08:58:00 +0200 [thread overview]
Message-ID: <45E67978.9030805@dawes.za.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0703010208070.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 28 Feb 2007, Rogan Dawes wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Wed, 28 Feb 2007, Rogan Dawes wrote:
>>>
>>>> How about showing the size of the changes between the 2 files via
>>>> the libxdiff binary patch function?
>>> I briefly considered this, too. But what would it tell you in the case
>>> of a jpg? I think it has more disadvantages than advantages...
>> It would still tell you the extent of the changes. i.e. Did we change
>> only 10 bytes of the file, or is it a dramatic change?
>
> I was not explicit enough, okay. I was not so worried about the case where
> only 10 bytes changed. If you insert a single dot in a jpg image, chances
> are that your binary content will change _a lot_.
>
> So, no problem deducing from 10 bytes changed that it was a minor change.
> But you cannot deduce the opposite of a 1MB change!
>
> Hth,
> Dscho
>
Yeah, I did understand that.
However, if we were to generalise, making a change to an XML document
(wrapping the whole thing in an additional tag, with the associated
indentation adjustments), we'd still see all the lines in the file
change, even though the actual (semantic?) change is small. However, we
would still report the full numbers of lines added and deleted regardless.
Why should a binary file be any different? It would be up to the
observer to make a conclusion as to the significance of the numbers,
based on their intrinsic knowledge of the file type, and its properties.
I just believe that showing bytes changed for binary files is
_consistent_ with what we do for text.
Rogan
next prev parent reply other threads:[~2007-03-01 6:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-28 13:03 [PATCH] Show binary file size change in diff --stat Andy Parkins
2007-02-28 14:44 ` Johannes Schindelin
2007-02-28 14:51 ` Nicolas Pitre
2007-02-28 15:15 ` Andy Parkins
2007-02-28 15:37 ` Johannes Schindelin
2007-02-28 18:42 ` Andy Parkins
2007-02-28 19:41 ` Johannes Schindelin
2007-02-28 15:26 ` Andy Parkins
2007-02-28 18:58 ` Rogan Dawes
2007-02-28 19:42 ` Johannes Schindelin
2007-02-28 21:27 ` Rogan Dawes
2007-03-01 1:09 ` Johannes Schindelin
2007-03-01 6:58 ` Rogan Dawes [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-04-04 13:14 Andy Parkins
2007-04-04 13:34 ` Rogan Dawes
2007-04-04 14:40 ` Geert Bosch
2007-04-04 16:00 ` Rogan Dawes
2007-04-04 14:40 ` Andy Parkins
2007-04-04 15:51 ` Rogan Dawes
2007-04-04 16:22 ` Johannes Schindelin
2007-04-04 16:26 ` Rogan Dawes
2007-04-04 16:40 ` Linus Torvalds
2007-04-04 16:59 ` Johannes Schindelin
2007-04-04 17:12 ` Linus Torvalds
2007-04-04 17:47 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45E67978.9030805@dawes.za.net \
--to=discard@dawes.za.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).