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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 20, 2012, 00:26 UTC
Message-ID: <7vobm6o1cu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <9E4BBC27-5B26-4048-93D4-FE02C550F4E2@gmail.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?