Christian Couder <chriscool@xxxxxxxxxxxxx> writes:
> In "parse_commit_buffer", the parent sha1s from the original commit
> or from a commit graft that match a ref name in "refs/replace/" are
> replaced by the commit sha1 that has been read in the ref.
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.
--
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
