Re: ghost refs

[Jeff King <peff@peff.net>]

On Tue, Apr 20, 2010 at 10:52:42AM -0400, Jay Soffian wrote:

> On Tue, Apr 20, 2010 at 10:24 AM, Jeff King <peff@peff.net> wrote:
> > On Tue, Apr 20, 2010 at 09:33:42AM -0400, Jay Soffian wrote:
> > I like how the user would interact with that, but what happens with:
> >
> >  git checkout -b topic/subtopic
> >
> > The reflog of the deleted branch is in the way.
> 
> Handle it just as gracefully as we do today. This is what happens when
> you try to create a branch with a similar collision:
> 
> $ git branch foo/bar
> $ git branch foo
> error: there are still refs under 'refs/heads/foo'
> fatal: Failed to lock ref for update: Is a directory

Yeah, but my next step would be "branch -d foo/bar"; under your proposal
that no longer works. Now I have to do "branch -m foo/bar foobar" where
"foobar" is some name that I know means "the old reflog for foo/bar".

So I think it makes more sense to come up with that naming scheme
ourselves and make using it semi-transparent.

> $ git branch topic/subtopic
> error: there are still logs under 'logs/refs/heads/topic'
> fatal: Failed to lock log for update: Is a directory
> 
> I think it's an edge case; thus I think it's okay to fail as long as
> we give a reasonable error and a way to rename it.

It is an edge-case, but I'd rather just have a scheme that works nicely
in the normal case and "degrades" only in the error case. Like if
creating "foo/bar" we see that we have "foo", but that the last reflog
entry is deletion, we move "foo" to "foo-1" or something. It's ugly, but
it just doesn't come up that much.

-Peff