Re: ghost refs

From: Yann Dirson <dirson@bertin.fr>
Date: Apr 20, 2010, 13:00 UTC
Message-ID: <20100420150015.4bd80387@chalon.bertin.fr>
In-Reply-To: <20100420120228.GM17930@lake.fysh.org>

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

Show 11 quoted lines

> 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