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

Re: Better big file support & GSoC

From
Carlos Martín Nieto <cmn@elego.de>
Date
Apr 2, 2011, 15:30 UTC
Message-ID
<20110402153008.GA5921@centaur.lab.cmartin.tk>
In-Reply-To
<20110402164051.1f263aa0@RunningPinguin.chalmion.homelinux.net>
On Sat, Apr 02, 2011 at 04:40:51PM +0200, Jonathan Michalon wrote:
Show 21 quoted lines
> [...]
> Eric Montellese says: "Don't track binaries in git. Track their hashes." I agree
> here too. We should not treat computer data like source code (or whatever text).
> He claims that he needs to handle repos containing source code + zipped tarballs
> + large and/or many binaries. Users seem to really need binary tracking and
> therefore git should do it. I personally needed to a couple of times.
> 
> He also says that we could want to do download-as-needed and remove-unnecessary
> operations, and I think that it may be clean enough to add a git command like
> 'git blob' to handle special operations for binaries. Perhaps in a second step.
> 
> Another idea was to create "sparse" repos, considered leafs as they may not be
> cloned from because they lack full data. But it may or may not be in the
> spirit of Git...
> 
> 
> What I personally would like as a feature is the ability to store the main
> repo with sources etc. into a conventional repo but put the data elsewhere
> on a storage location. This would allow to develop programs which need data
> to run (like textures in games etc.) without making the repo slow, big or
> just messy.
 This sounds a lot like like what git-annex [0] does. Maybe
 integrating its functionality with mainline git could be a good
 start.
[0] http://git-annex.branchable.com/
   cmn
-- 
Carlos Martín Nieto | http://cmartin.tk
Previous: Jonathan MichalonNext: Jonathan Michalon
Message 2 of 5 in “Better big file support & GSoC”
  1. Jonathan MichalonApr 2, 2011
  2. Carlos Martín NietoApr 2, 2011
  3. Jonathan MichalonApr 4, 2011
  4. david@lang.hmApr 3, 2011
  5. Jonathan MichalonApr 4, 2011

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.