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. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html