Re: git equivalent to clearcase wink-in
- From
Johan Herland <johan@herland.net>
- Date
- Jan 21, 2010, 01:51 UTC
- Message-ID
- <201001210251.24948.johan@herland.net>
- In-Reply-To
- <fabb9a1e1001201434n1036253ds1120c2abc0d3728e@mail.gmail.com>
On Wednesday 20 January 2010, Sverre Rabbelier wrote:
Show 8 quoted lines
> 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