On Sat, Jun 01, 2013 at 05:00:07AM +0200, Michael Haggerty wrote:

> This is a known problem.  The technical reason that this is not trivial
> to solve is the possibility of a directory/file conflict between old
> reflog files and references that might be created subsequently (which in
> turn is a limitation of how loose references and reflogs are mapped to
> filenames):
> [...]
> Peff proposed a solution to this problem [1], but AFAIK it is not making
> progress.

I was running with the patch series you mentioned for a while, but there
are some weird bugs with it that need to be tracked down.  I don't
recall the details, but I would occasionally get error messages that
showed that some parts of the code were surprised that the reflog
existed without the ref existing.

While I think solving the D/F conflict in the ref namespaces overall
would be a nice thing to have, doing it with compatibility with the
current system is complex and error-prone. I wonder if simply sticking
the reflog entries into a big GRAVEYARD reflog wouldn't be a great deal
simpler and accomplish the "keep deleted reflogs" goal, which is what
people actually want.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to