On Tue, Apr 20, 2010 at 07:02:05AM +0000, Yann Dirson wrote:
> > You do have a reflog in the case of overwrite. Delete kills off any
> > associated reflog (it would be cool if we had a "graveyard" reflog that
> > kept deleted branch reflogs around for a while).
>
> Wouldn't it jus be sufficient to keep reflogs on branch deletion, and
> let reflog entries subject be expired by gc just like for any branch,
> so that way we may only need to gc the reflog itself when it becomes
> empty ?
Almost. The complication is that a branch "foo" prevents any branch
"foo/bar" from being created. So if you leave the reflog in place, you
are blocking the creation of the reflog for a new branch.
So you need some solution to that problem. Things I thought of are:
1. Leave the reflog in place until such a foo/bar branch is created.
But that means branch creation unexpectedly kills off old unrelated
reflog entries. Combingin user surprise and destruction of data is
probably bad.
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.
3. Stick everything in a big "graveyard" reflog. I think there are
some complications here with the reflog format, though. Namely:
- reflog entries don't actually name the ref they're on. We could
munge the comment field to add the name of the ref as we put
them in the graveyard ref.
- entries just have a timestamp, and I think we assume they're in
order. So I guess we can merge-sort the old graveyard ref with
what we're adding to keep things in order. But it means you
will have entries from various refs interspersed. I guess that
is OK, though, as it's not unlike the HEAD reflog.
So (3) seems like the only viable option to me, but I would be happy to
hear alternatives.
-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