Le samedi 3 janvier 2009, Junio C Hamano a écrit : > Christian Couder <chriscool@xxxxxxxxxxxxx> 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. 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. -- 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
