Re: [RFC] origin link for cherry-pick and revert
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Sep 12, 2008, 15:11 UTC
- Message-ID
- <200809121711.32448.jnareb@gmail.com>
- In-Reply-To
- <20080912145802.GV5082@mit.edu>
Theodore Tso wrote:
Show 22 quoted lines
> 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