git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git and binary files

From
PMPetko Manolov <petkan@nucleusys.com>
Date
Jan 16, 2008, 14:14 UTC
Message-ID
<alpine.DEB.1.00.0801161606160.5260@bender.nucleusys.com>
In-Reply-To
<20080116135420.GA21588@coredump.intra.peff.net>
On Wed, 16 Jan 2008, Jeff King wrote:
Show 11 quoted lines
> On Wed, Jan 16, 2008 at 03:39:06PM +0200, Petko Manolov wrote:
>
>> What i am trying to suggest is that there might be cases when you need
>> something in the repository, but you don't want GIT to keep it's history
>> nor it's predecessors.  Leaving it out breaks the atomicity of such
>> repository and makes the project management more complex.
>
> But not versioning some files while versioning others breaks the
> atomicity of project version, which is at the core of git's model. There
> is no such thing as "this file is at revision X, but that one is at
> revision Y." There is only "the project is at revision X."
Sigh.  You are right.

However, the said project is kind of exception. The binaries are there from the very beginning - they are indivisible part of the project and it won't work without them. This is why i am not worried if i revert to previous source code version, but actually check-out fresh binary - in my case it won't break things.

Show 11 quoted lines
>> There's a few examples out there that shows how to solve this, but it
>> seems inconvenient and involves branching, cloning, etc.  Isn't it
>> possible to add something like:
>>
>> 	"git nohistory firmware.bin"
>>
>> or
>> 	"git nohistory -i-understand-this-might-be-dangerous firmware.bin"
>
> Not easily. It goes against the underlying data model at the core of
> git.
Damn, i knew you'd say something like this. :-)
> How big are your firmware files? How often do they change, and how large 
> are the changes? IOW, have you confirmed that repacking does not produce 
> an acceptable delta, meaning you get versioning for very low space cost?

Changes don't happen too often, but the size of everything binary in the tree easily goes to about 100MB. Three commits later it ends up at about 300MB...

cheers, Petko

Previous: Jeff KingNext: Jeff King
Message 26 of 32 in “git and binary files”
  1. Petko ManolovJan 16, 2008
  2. David SymondsJan 16, 2008
  3. Petko ManolovJan 16, 2008
  4. Johannes SchindelinJan 16, 2008
  5. Petko ManolovJan 16, 2008
  6. Johannes SchindelinJan 16, 2008
  7. Petko ManolovJan 16, 2008
  8. Wincent ColaiutaJan 16, 2008
  9. Petko ManolovJan 16, 2008
  10. Junio C HamanoJan 16, 2008
  11. Junio C HamanoJan 16, 2008
  12. Johannes SchindelinJan 16, 2008
  13. Petko ManolovJan 16, 2008
  14. Jakub NarebskiJan 16, 2008
  15. Petko ManolovJan 16, 2008
  16. Jakub NarebskiJan 16, 2008
  17. Petko ManolovJan 16, 2008
  18. Nicolas PitreJan 16, 2008
  19. Petko ManolovJan 16, 2008
  20. Nicolas PitreJan 16, 2008
  21. Petko ManolovJan 16, 2008
  22. Petko ManolovJan 16, 2008
  23. Jakub NarebskiJan 16, 2008
  24. Florian WeimerJan 16, 2008
  25. Jeff KingJan 16, 2008
  26. Petko ManolovJan 16, 2008
  27. Jeff KingJan 16, 2008
  28. Petko ManolovJan 16, 2008
  29. Jeff KingJan 16, 2008
  30. Petko ManolovJan 16, 2008
  31. Rogan DawesJan 16, 2008
  32. David BrownJan 18, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.