Theodore Tso wrote: > On Fri, Sep 12, 2008 at 07:47:39AM +0200, Stephen R. van den Berg wrote: >>> >>>You could add it as a >>> >>> Original-patch-id: <sha1> >> >> That will probably work fine when operating locally on (short) temporary >> branches. >> >> It would probably become computationally prohibitive to use it between >> long lived permanent branches. In that case it would need to be >> augmented by the sha1 of the originating commit. > > Nope, as Sam suggested in his original message (but which got clipped > by Linus when he was replying) all you have to do is to have a > separate local database which ties commits and patch-id's together as > a cache/index. > > I know you seem to be resistent to caches, but caches are **good** > because they are local information, which by definition can be > implementation-dependent; you can always generate the cache from the > git repository if for some reason you need to extend it. [...] But it is not true that "you can always generate the cache from the git repository" in this case; the patch-id that is to be saved is _original_ patch-id of cherry-picked (or reverted) changeset. OTOH it is not much different from reflog information, which also cannot be regenerated from object database. -- Jakub Narebski Poland -- 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
