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

Le samedi 3 janvier 2009, Junio C Hamano a écrit :

Christian Couder [off-list ref] writes:

quoted

Le mardi 30 décembre 2008, Junio C Hamano a écrit :

quoted

* 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.

Ok. When I first implemented "bisect replace" I saw that I could reuse the 
graft fix-up mechanism. And as you talked about replacing grafts, I thought 
that you wanted the implementation to use that mechanism instead of adding 
a different one.

But I agree that it may be more powerfull and generic to replace objects the 
way you describe it. So I will work on that.

Thanks,
Christian.