Alexey Muranov <alexey.mura...@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? -- 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
