Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)

> Christian Couder <chriscool@tuxfamily.org> writes:
> > Le mardi 30 décembre 2008, Junio C Hamano a écrit :
> >> * cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
> >>  - bisect: add "--no-replace" option to bisect without using replace
> >>    refs
> >>  - rev-list: make it possible to disable replacing using "--no-
> >>    bisect-replace"
> >>  - bisect: use "--bisect-replace" options when checking merge bases
> >>  - merge-base: add "--bisect-replace" option to use fixed up revs
> >>  - commit: add "bisect_replace_all" prototype to "commit.h"
> >>  - rev-list: add "--bisect-replace" to list revisions with fixed up
> >>    history
> >>  - Documentation: add "git bisect replace" documentation
> >>  - bisect: add test cases for "git bisect replace"
> >>  - bisect: add "git bisect replace" subcommand
> >>
> >> I think a mechanism like this should be added to replace grafts,
> >
> > The problem with replacing grafts is that a graft can specify many
> > parents for one commit while a ref associates only one object to a
> > name.
>
> Sorry, maybe I misunderstood your implementation.  What I thought we
> discussed during GitTogether was to write out the object name of the
> replacement object in refs/replace/<sha1>.
>
> When the caller asks read_sha1_file() for an object whose object name is
> <sha1>, you see if there is refs/replace/<sha1> in the repository, and
> read the ref to learn the object name of the object that replaces it. 
> And you return that as if it is the original object.