Re: [RFC] origin link for cherry-pick and revert
- From
Theodore Tso <tytso@mit.edu>
- Date
- Sep 12, 2008, 14:58 UTC
- Message-ID
- <20080912145802.GV5082@mit.edu>
- In-Reply-To
- <20080912054739.GB22228@cuci.nl>
On Fri, Sep 12, 2008 at 07:47:39AM +0200, Stephen R. van den Berg wrote:
Show 10 quoted lines
> >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. It also means that if it turns out you need to index reationships a different way, you can do that without having to make fundamental (incompatible) changes in the git object.
It's much like SQL databases; you have your database tables, where making changes to the database schema is painful --- and indexes, which can be added and dropped with much less effort. Think of these local caches are database indexes. Just because you need an index in a particular direction to optimize a query or loopup operation does ***not*** imply that you need to make a fundamental, globally visible, database schema change or git object layout which breaks compatibility for everybody.
- Ted