On Fri, Aug 07, 2015 at 06:50:52PM -0400, Jarkko Hietaniemi wrote:
> Or another way to illustrate my idea: assume a create-once-no-delete
> filesystem.
>
> echo 42 > the_answr.txt
>
> Oh, darn it...
>
> ln -s the_answr.txt the_answer.txt
>
> Now both names still point to the content "42\n". The first SHA
> would be over ["42\n", "the_answr.txt"] and the second SHA over
> ["42\n", "the_answer.txt"].
But you can't do that on a create-once filesystem; your symlink
overwrites "the_answr.txt", which already exists. Obviously that is a
technicality in the definition of "create-once", but if we take this as
an analogy for a content-addressable object store, it is true. :) The
name "answr.txt" in your case is really a sha1 "1234abcd", and we cannot
create an object of that name that has anything _but_ the specific
matching content in it. Your options are then:
- add a level of indirection; when we look up 1234abcd, show some
other object instead (even though its content does not match
1234abcd). We have this already; it is the git-replace mechanism.
- during certain operations (e.g., showing the log), use 1234abcd as
an index into another data store. We have this, too: git-notes.
I think I saw the objection elsewhere in the thread that these are not
seamless to use. That is certainly true. Partially this is inherent
(the client has to understand the extra object, and know when you want
that object versus the original). But git could also improve its
handling of these things.
For instance, we do not fetch notes from a remote by default. The big
problems is that the refs/remotes hierarchy is set really set up only to
hold branches, so we do not know where to put them. There was a
discussion around the v1.8.0 time-frame about improving this[1], but it
was never completed. That might be a productive direction if anyone is
really interested in this topic.
-Peff
[1] I didn't re-read the old thread, but glancing through, this looks
like a reasonable jumping-off point for reading:
http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165885
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html