Re: [RFC/PATCH 2/3] replace_object: add mechanism to replace objects found in "refs/replace/"

[Jakub Narebski <jnareb@gmail.com>]

On Mon, 12 Jan 2009, Tim 'mithro' Ansell wrote:

> > I just had an idea: we can use this mechanism to better manage large
> > binary files in Git, by using replacements for _blobs_.
> > 
> > We want to be able to have two flavours of repository: one with large
> > blobs (media files usually), and one without.  We can use stubs in the
> > place of large binary files in 'no-megablobs' flavor, and add contents
> > of those files via refs/replace/* for _blobs_ in 'with-megablobs'
> > flavour.  We can control which objects we want to have, and which
> > objects to transfer.
> > 
> > What do you think about this (abuse of) an idea?
> 
> I'm not sure I understand. I don't really care much about the
> implementation details if it's transparent to the user :)
> 
> I have not really had much time to pursue my idea of getting sha1_file
> to read download blob on an as-needed basis (work has been hectic).

Actually this idea is a bit different from lazy / on demand downloading
of large blobs.


In "on demand loading" solution you have sha-1 of _full_ blob in a tree,
but git knows that not having it is not a fatal error (somehow), and you
can ask git to download it. This is as far as I understand the solution
you proposed and partially implemented.

In "replacement blobs" solution, the (ab)use of object replacement
mechanism meant originally for easier bisect, you have sha-1 of _stub_
object in a tree.  If you want full (large) blob, you add replacement
in refs/replace/*, replacing stub blob object (must be unique; it can
for example contain some header + sha-1 of full object) with full
object.  If you want to have large object, you need to transfer 
refs/replace/*.  This solution means that user needs to be aware of
this mechanism, or have some wrapper (script) around it.


Different solution, and a bit different behavior wrt getting large
object for the user.

-- 
Jakub Narebski
Poland