Re: [RFC] origin link for cherry-pick and revert

From: Stephen R. van den Berg <srb@cuci.nl>
Date: Sep 10, 2008, 22:34 UTC
Message-ID: <20080910223427.GB22739@cuci.nl>
In-Reply-To: <20080910215410.GA24432@coredump.intra.peff.net>

Jeff King wrote:

Show 6 quoted lines

>On Wed, Sep 10, 2008 at 11:50:45PM +0200, Stephen R. van den Berg wrote:
>> >There was a proposal at some point for a "notes" feature which would
>> >allow after-the-fact annotation of commits. I don't recall the exact
>> >details, but I think it stored its information as a git tree of blobs.
>> >You could choose whether or not to transfer the notes based on
>> >transferring a ref pointing to the notes tree.

>> The idea is nice, but if we were to use it to store the origin link
>> information, the following happens:
>> - Origin link information is rare.

Show 5 quoted lines

>I think you are misunderstanding what I meant by "git tree" here. It is
>literally a git tree object, so you don't ask the filesystem at all. You
>are looking up within the single object file. If it's a miss, you know
>after seeing that object. If not, then you dereference the blob object
>that contains the notes.

I see. Indeed. That's a lot better. Did the binary search inside tree objects ever get implemented?

It is unclear why the latest commit notes proposal didn't make it, though I admit that storing the origin link information in there seems feasible.

The downsides when doing that are:
- The lookup cost is small, but still noticable, since it is sometimes
  done on every commit; using the in-commit origin headerfield solves
  this at negligible cost.
- The origin information is no longer cryptographically protected (under
  certain circumstances this could be considered an advantage and a
  disadvantage at the same time).

-- 
Sincerely,
           Stephen R. van den Berg.

"Am I paying for this abuse or is it extra?"