git equivalent to clearcase wink-in

To whom it may concer,

I have been playing with git recently, and I like it very much.  I was wondering if you can tell me if git has something that is equivalent to clearcase wink-in functionality.  The reason I ask, if it takes 1 hour to build my repository, then every clone of my repository will also take one hour to build at the remote location.  In clearcase you can wink in objects that have already been built.  time to wink in could just be minutes rather than waiting a full hour for all the binaries to build.

Can you help me out here?  I would like to know if git has something similar.

Richard.

Would something like ccache (compiler cache) help you out? It's not the same as wink-in (which, as I understand it, copies an already built object file from someone else who has built it). Instead each user has their own cache, so everyone has to pay the expensive build price at least once.

It also only works for C/C++, I think.

-- Jamie

On Wed, Jan 20, 2010 at 3:20 PM, Richard Assal <richard_assal@yahoo.com> wrote:

On Wed, Jan 20, 2010 at 04:05:46PM -0500, Jamie Wellnitz 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)

Mike

Heya,

On Wed, Jan 20, 2010 at 22:12, Mike Hommey <mh@glandium.org> wrote:

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?

On Wednesday 20 January 2010, Sverre Rabbelier wrote:

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

Mike Hommey <mh@glandium.org> writes:

There's a section "SHARING A CACHE" here: http://ccache.samba.org/ccache-man.html

onsdagen den 20 januari 2010 22.05.46 skrev  Jamie Wellnitz:

Judging from the documentation you can share the cache with others.

-- robin