On Tue, Apr 20, 2010 at 07:02:05AM +0000, Yann Dirson wrote:

quoted text
> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html