Re: wishlist: make it possible to amend commit messages after push to remote

From: Jeff King <peff@peff.net>
Date: Aug 8, 2015, 09:24 UTC
Message-ID: <20150808092432.GB24707@sigill.intra.peff.net>
In-Reply-To: <55C5364C.6040904@iki.fi>

On Fri, Aug 07, 2015 at 06:50:52PM -0400, Jarkko Hietaniemi wrote:

Show 12 quoted lines

> 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