Re: [PATCH 1/3] retain reflogs for deleted refs

[Jeff King <peff@peff.net>]

On Sun, Jul 22, 2012 at 01:10:55PM +0200, Alexey Muranov wrote:

> >>>   refs/heads/a
> >>>   refs/heads/a/b
> >>>   refs/heads/a/b/c
> >>> 
> >>> will be stored in:
> >>> 
> >>>   logs/graveyard/refs/heads/a~
> >>>   logs/graveyard/refs/heads/a/b~
> >>>   logs/graveyard/refs/heads/a/b/c~
> >>> 
> >>> Putting them in the graveyard namespace ensures they will
> >>> not conflict with live refs, and the tilde prevents D/F
> >>> conflicts within the graveyard namespace.
> 
> Sorry if this idea is stupid or if i miss something, but how about putting deleted reflogs for
> 
> refs/heads/a
> refs/heads/a/b
> refs/heads/a/b/c
> 
> to
> 
> refs/heads/a@yyyy-mm-dd-hhmmss
> refs/heads/a/b@yyyy-mm-dd-hhmmss
> refs/heads/a/b/c@yyyy-mm-dd-hhmmss
> 
> with the time they were deleted?

I like the readability of the resulting file names, but it has three
problems:

  1. "@" is allowed in ref names, so you may be conflicting with
     existing refs. You could fix that by using "@{...}", which is
     disallowed. E.g., refs/heads/a@{yyyy-mm-dd-hhmmss}.

  2. It makes lookup slightly more expensive, because to find a reflog
     for "refs/heads/a", I have to scan "logs/refs/heads" looking for
     any matching entries of the form "a@{.*}". This is probably not a
     huge deal in practice, though it does make the code more complex.

  3. Most importantly, it does not resolve D/F conflicts (it has the
     same problem as "logs/refs/heads/a~"). If you delete "foo/bar", you
     will end up with "logs/refs/heads/foo/bar@{...}". That will prevent
     D/F conflicts with a new branch "foo/bar/baz", but will still have
     a problem with just "foo".

     You need to either mark each directory to avoid the conflict
     (Michael suggested something like "refs/heads~/foo~/bar"), or
     you need to put the deleted logs into a separate hierarchy (I used
     "logs/graveyard" in my patch).

-Peff