Re: ghost refs

[Yann Dirson <dirson@bertin.fr>]

Le Tue, 20 Apr 2010 13:02:28 +0100,
Zefram <zefram@fysh.org> a écrit :

> Jeff King wrote:
> >  2. Make a refs/dead hierarchy so that the reflogs don't interfere
> > with new branches. This just pushes off the problem, though, for
> > when you try to delete "foo/bar" and see that "refs/dead/foo" is
> > already blocking its spot in the reflog graveyard.
> 
> This is easily solved by tweaking the name for dead reflogs.
> logs/dead_refs/foo~ doesn't clash with logs/dead_refs/foo/bar~.
>
> You might also want to stick a sequence number into the filename, for
> when you delete more than one foo/bar branch.

That sounds cool.  A logs/dead_refs/ namespace of some sort seems to be
unavoidable, to avoid the clash between old "logs/refs/foo/bar~"
and new "logs/refs/foo".

We would also need a syntax for accessing those.  Maybe something
reminiscent of Debian "epochs" in version number.  That would
give a syntax like "foo@{1:1}" and "foo@{2:1}" to access the dead and
long-dead refs' logs, respectively looking into foo~<largest> and
foo~<largest-1>.

Going that way, we would probably want to add a "delete" entries in the
reflog when deleting a ref - but that would make "foo@{1:0}" a
non-sense, we could just reject it.


Another option than adding a sequence number would be to move back the
dead_refs/ log back to refs/ when the branch is creating again.  That
way just after resurection we have:

	foo@{0}	: now
	foo@{1} : invalid (deleted state)
	foo@{2} : the ref as it was 2 operations before

That would kinda make sense too, but then if the new "foo" is something
completely unrelated, we may rather want to refer to foo{1:1}
(which is stable until next deletion of foo) rather than foo@{2}, which
varies with current foo.  But the 1st solution could give us that too,
by considering logs/dead_refs/foo~ the logical continuation of
logs/refs/foo.

Would that make sense ?
-- 
Yann