Le Tue, 20 Apr 2010 13:02:28 +0100,
Zefram <zefram@xxxxxxxx> 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
--
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