Re: reftable [v4]: new ref storage format

From: Shawn Pearce <spearce@spearce.org>
Date: Aug 1, 2017, 15:27 UTC
Message-ID: <CAJo=hJvsBTDO-8OxrxwfV-=4XWW1w-616DGu31aVb5EU7DWcDA@mail.gmail.com>
In-Reply-To: <CAD0k6qTFV2AAbWiKvi4=OoodoXEgxswLEbraC3xP1LzvtRRaGg@mail.gmail.com>

On Tue, Aug 1, 2017 at 6:54 AM, Dave Borowitz <dborowitz@google.com> wrote:

Show 14 quoted lines

> On Sun, Jul 30, 2017 at 11:51 PM, Shawn Pearce <spearce@spearce.org> wrote:
>> - Ref-like files (FETCH_HEAD, MERGE_HEAD) also use type 0x3.
>
>> - Combine reflog storage with ref storage for small transactions.
>> - Separate reflog storage for base refs and historical logs.
>
> How is the stash implemented in reftable? In particular, "git stash
> drop" needs to be able to remove an arbitrary single entry from a
> reflog.
>
> I don't think the current proposal supports writing tombstones for
> reflog entries, so this maybe implies that "stash drop" would have to
> be implemented by rewriting the whole reflog for the stash ref during
> compaction. Can the current compaction algorithm support this?

Yes, the reftable holding the stash would have to be completely rewritten for a "stash drop" command to be able to remove a reflog entry.

Show 6 quoted lines

> I suppose there are more exotic alternatives:
> * Go back to the normal ref(log) format for refs/stash. I figure you
> probably don't want to do this, given that you already moved other
> ref-like files into the reftable in a later revision of this proposal.
> * Implement the whole stash storage/command in some other way that
> doesn't depend on reflog.

I think the simplest is just put refs/stash in its own reftable, and put that reftable in the stack somewhere. Editing refs/stash reflog requires rewriting and replacing that reftable in the stack, but otherwise doesn't impact any other (possibly much larger) reflog.

Pushing things onto refs/stash would be creating new small transaction reftables on the top of the stack, which should be compacted with the lower refs/stash table. I guess that means refs/stash needs special handling in some of the compaction code to keep it isolated.