On Tue, Aug 1, 2017 at 6:54 AM, Dave Borowitz <dborowitz@xxxxxxxxxx> wrote: > On Sun, Jul 30, 2017 at 11:51 PM, Shawn Pearce <spearce@xxxxxxxxxxx> 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. > 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.
