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
--
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