Theodore Tso wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html