Le jeudi 15 janvier 2009, Christian Couder a écrit : > Le mardi 13 janvier 2009, Junio C Hamano a écrit : > > > Since your paradigm is prepare replacement once at the beginning, never > > allowing to update it, I think you can update the table while you look > > it up. E.g. if A->B and B->C exists, and A is asked for, you find A->B > > (to tentatively make cur to point at B) and then you find B->C, and > > before returning you can rewrite the first mapping to A->C. Later > > look-up won't need to dereference the table twice that way. > > > > This assumes that there will be small number of replacements, but the > > same object can be asked for more than once during the process. > > If we allow different sets of replace refs, for example A->B > in "refs/replace/" and B->C in "refs/replace/bisect/", then we cannot > rewrite as you suggest. We could add A->C in "refs/replace/bisect/", so > that it overcomes A->B and B->C when we bisect, but we would not gain > much. Sorry, I just realized I misunderstood what you said. I don't know why but I thought you talked about updating the refs. But in fact you are right it should be possible to update the "replace_object" table. Regards, 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
