Thread (4 messages) flat view 4 messages, 2 authors, 2016-06-15

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

From: Alexey Muranov <hidden>
Date: 2016-06-15 22:54:30

On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
Alexey Muranov [off-list ref] writes:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help