Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change

[Junio C Hamano <gitster@pobox.com>]

Alexey Muranov <alexey.muranov@gmail.com> writes:

> I only suggested how to resolve conflicts between dead reflogs in
> graveyard if "next" and "next/foo" cannot coexist.

But Jeff's patch series already has the support for a case where you
delete next (graveyard gets 'next'), create next/foo and then delete
that (graveyard gets 'next/foo', too) anyway (check the list archive
before posting).  It is a solved problem.

> It is possible to collect the information for "git log -g
> next/foo" by looking through all "timestamp" subdirectories in
> graveyard.

It is possible if you wrote a new file every time you add one entry
to reflog, or if you created a directory with timestamp in its name
and wrote a new file there, too.

We are not particularly interested in "it is possible" when many
implementations can all trivially allow it to be "possible"; the
question is what a sensible solution is among them, and I didn't
find "a directory with timestamp in its name" a particularly
sensible way to go.

Either Jeff's "refname $name's log goes to logs/graveyard/$name~" or
Michael's "append ~d to each directory component, append ~f to the
leaf component" that are already proposed will keep "one file per
name" property to allow us to open once and efficiently read the
file through.  Why would we want to see an inferiour alternative
added to the discussion?