Re: git equivalent to clearcase wink-in

[Johan Herland <johan@herland.net>]

On Wednesday 20 January 2010, Sverre Rabbelier wrote:
> On Wed, Jan 20, 2010 at 22:12, Mike Hommey <mh@glandium.org> wrote:
> > Surely the ccache directory could be shared on nfs or some other
> > network filesystem. Or object file could be checked in, which is imho
> > ugly, but should work (better to do that on a separate branch)
> 
> Ha! It could even be stored as a note on the tree object? The whole
> notes business seems to be nearing a usable stage. Or maybe notes are
> text-only, mhhh. Johan?

In principle you could (ab)use the notes structure for this purpose. There 
is nothing inherently text-only about notes. I would certainly suggest to 
create a custom notes ref for this purpose, so that these object caches are 
not mixed up with other notes (and are also not displayed by git log).

I'm also not sure the putting the note on the tree object is the right 
granularity. You could imagine putting a .o-file as a note on the 
corresponding .c-file _blob_, but that would only work if the .o-file 
depended solely on the .c file (i.e. it would only work for preprocessed 
source, or .c-files without any #includes), so that is probably not viable.

The problem with putting the object cache on the tree object, is that it 
would only be useful for those building the exact same tree as the one where 
the cache was made. Even though ccache can handle changed files just fine, 
you would not be able to leverage it, since the cache would be hidden under 
a different tree object.


Here's is an even more extreme idea: AFAIK, ccache works by hashing a 
preprocessed source file, and mapping the hash value to the resulting object 
file. A later lookup of the same preprocessed source file will yield the 
object file without having to go through that pesky compilation.

Now, what if that hash function happened to be SHA1, and the mapping 
happened to be the Git object database? In other words you could create a 
notes tree where the keys are SHA1s from preprocessed source files, and the 
note objects are the corresponding object files. As long as you don't call 
gc_notes() on this notes tree, it doesn't really matter that your SHA1 keys 
do not really exist as objects in the Git repo. The notes code can happily 
map any arbitrary SHA1 sum to a note object; it's only in gc_notes() that we 
actually care whether that SHA1 identifies an existing Git object.


Oh, and BTW, I consider the notes feature to be ready for prime time once 
the patch series currently in 'pu' is fully merged.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net