git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Spurious line insertion/deletion stats for binary file
@ 2010-10-12 22:47 Kevin Ballard
  2010-10-15 19:26 ` Neal Kreitzinger
  0 siblings, 1 reply; 2+ messages in thread
From: Kevin Ballard @ 2010-10-12 22:47 UTC (permalink / raw)
  To: Git Mailing List

I just noticed something fairly odd when making a commit that changed a single binary file:

kevin> (develop +=)> git ci -m 'Replace binary file'
[develop c0c3b98] Replace binary file
 1 files changed, 8 insertions(+), 14 deletions(-)
 rewrite Resources/some_image.png (99%)

The commit results seem to be treating the binary file as text in order to give me insertion/deletion stats. This is quite obviously wrong. For this situation, a fairly simple solution would be to change that line to something like

 1 files changed, 2652 bytes removed

but the correct behavior is a bit less obvious when there are multiple files changed. Does anyone have a good suggestion for how to handle this case?

-Kevin Ballard

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Spurious line insertion/deletion stats for binary file
  2010-10-12 22:47 Spurious line insertion/deletion stats for binary file Kevin Ballard
@ 2010-10-15 19:26 ` Neal Kreitzinger
  0 siblings, 0 replies; 2+ messages in thread
From: Neal Kreitzinger @ 2010-10-15 19:26 UTC (permalink / raw)
  To: git

"Kevin Ballard" <kevin@sb.org> wrote in message 
news:8CFCE61F-591A-4B56-B701-D1A391FBB088@sb.org...
>I just noticed something fairly odd when making a commit that changed a 
>single binary file:
>
> kevin> (develop +=)> git ci -m 'Replace binary file'
> [develop c0c3b98] Replace binary file
> 1 files changed, 8 insertions(+), 14 deletions(-)
> rewrite Resources/some_image.png (99%)
>
> The commit results seem to be treating the binary file as text in order to 
> give me insertion/deletion stats. This is quite obviously wrong. For this 
> situation, a fairly simple solution would be to change that line to 
> something like
>
> 1 files changed, 2652 bytes removed
>
> but the correct behavior is a bit less obvious when there are multiple 
> files changed. Does anyone have a good suggestion for how to handle this 
> case?
>
> -Kevin Ballard--
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

We track all our binaries so each commit is a working state of our system. 
Git just seems to know they are binaries and reports them as such in the 
diff pane of gitk:  "Binary files a/path/binaryA and b/path/binaryA differ". 
We are currently using 1.7.1.  I guess it "knows" they are binaries because 
we don't their paths in the "gitattributes" file.

Based on the gitattributes manpage, it sounds like you have "diff" set for 
the path to your binary listed in your .git/info/attributes (git attributes) 
file.  If the binary is in the same path as the source you could set the 
"binary" attribute macro for your binary(s) if the path or name is 
distinguishable from the source.  I played around with this in the past, but 
currently don't have a need for it in my current configuration, so I'm 
getting all of this from the gitattributes manpage, 
http://www.kernel.org/pub/software/scm/git/docs/v1.7.1.2/gitattributes.html.

v/r,
Neal

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-10-15 19:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-12 22:47 Spurious line insertion/deletion stats for binary file Kevin Ballard
2010-10-15 19:26 ` Neal Kreitzinger

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).