Re: [RFC/PATCH 2/3] replace_object: add mechanism to replace objects found in "refs/replace/"

Christian Couder <chriscool@tuxfamily.org> writes:

I may be reading this wrong, but if you replace the parent of the commit, that won't improve anything over the graft mechanism, which we already have.

What I was hoping to see was to give replacing commit back when a commit is asked for by normal callers, while not replacing the objects when reachability traversal (prune, pack transfer and fsck) wants to read the commit. That way:

 (1) Normal callers will see the rewritten history (which is the same as
     graft); and

 (2) We will kill the design bug of the current graft mechanism that graft
     information cannot be transferred to the other end.  By using object
     replacement, you can fetch objects reachable from refs/replace/ at
     the other end and place them in the same refs/replace/ hierarchy
     locally, if you choose to use the same altered history, or you can
     choose not to use the replacement yourself.  The resulting repository
     is fully connected either way.

 (3) We will also kill the design bug of the current graft mechanism that
     graft information hides repository corruption to fsck.  The problem
     with this is that if you and then remove the grafts, you will end up
     with a corrupt repository, because these operations do look at grafts
     (this is justified only partly because otherwise you will lose
     objects that are reachable only via grafts, but is broken at the same
     time because you can lose the true parents by letting graft hide them
     from a reachable commit).

     By doing fsck and prune always using the true reachability, and using
     refs in the refs/replace/ hierarchy for protecting objects that are
     involved in this new way of grafting, you will ensure the integrity
     of the repository.  Removal of a ref from the refs/replace/ hierarchy
     won't result in such a corruption we can have today.

And that is exactly the reason why I was hoping the hook will be at read_sha1_file() that gives you a rewritten object contents when you ask for the original object, not at parse_commit_buffer which does not give you a rewritten object, but makes you follow to a rewritten object when parsing a commit (which itself is not replaced if it is the starting point).

Doing replacement at parse_commit_buffer() time is one step too late. For example, if you have replacement information for the commit that sits at the tip of 'master' branch, I think your "git log master" will ignore that replacement information. Creating one new commit on top of it and saying "git log master" then will show the new commit, and suddenly starts showing the replacement commit for the one you used to have at the tip of the branch.