On Wed, Feb 14, 2024 at 03:17:32PM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > In 5e00514745 (t1405: explictly delete reflogs for reftable, 2022-01-31)
> > we have added a test that explicitly deletes the reflog when not using
> > the "files" backend. This was required because back then, the "reftable"
> > backend didn't yet delete reflogs when deleting their corresponding
> > branches, and thus subsequent tests would fail because some unexpected
> > reflogs still exist.
> >
> > The "reftable" backend was eventually changed though so that it behaves
> > the same as the "files" backend and deletes reflogs when deleting refs.
> > This was done to make the "reftable" backend behave like the "files"
> > backend as closely as possible so that it can act as a drop-in
> > replacement.
> >
> > The cleanup-style test is thus not required anymore. Remove it.
> >
> > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> > ---
> >  t/t1405-main-ref-store.sh | 6 ------
> >  1 file changed, 6 deletions(-)
> 
> Again, makes sense.
> 
> This is a tangent, but artificial limitations we imposed on reftable
> to be more similar to files backend may be something we would want
> to reconsider once reftable hits mainline and people actively start
> using it.  Not having to lose the reflog only because you removed a
> branch by mistake would be a powerful thing, as it would allow you
> to resurrect the branch as well as its log.  Being able to have a
> branch 'foo', with work related to 'foo' kept inbranches 'foo/arc1'
> 'foo/arc2', etc., would be a very nice organizational tool.
> 
> But it is a good idea to start limited and later making it looser.
> These two limitations are something all users are already familiar
> with, so it is not as cripplingly bad as it smells anyway.

Yeah, I very much agree with what you say here. We have it in our
backlog to change this behaviour once the initial dust has settled.

Patrick