On 19 Aug 2012, at 02:02, Junio C Hamano wrote: > Alexey Muranov <alexey.mura...@gmail.com> writes: > >> Excuse me if i miss something again, but i might be willing to >> discuss the "ultimate destination". Could you possibly state in >> simple terms what the problem with determining the "ultimate >> destination" is? > > Decide if it makes sense to break backward compatibility of loose > ref representation merely to support having a branch "next" and > another branch "next/foo" in the same repository, and if it does, > what the new loose ref representation looks like.
I looked again through this thread and tried to understand better the issues. 1. I vote for moving dead reflogs to "logs/graveyard" (or to "logs/deadlogs"). 2. I think that allowing both "next" and "next/foo" complicates the mapping from branch names to file paths, and it does not seem necessary if dead reflogs are moved away to "graveyard" anyway. 3. There remains the question what to do with dead reflogs for different branches having the same name. Maybe, keep the death date and time under the graveyard directory and not allow the user to delete 2 times in less than 1 second? /logs/graveyard/yyyy-mm-dd-hhmmss/refs/heads/next/foo In a sense this is similar to the git storage model: an "atomic" destructive operation creates a timestamped "commit" in logs/graveyard directory.-- 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
