Re: ghost refs

From: Jeff King <peff@peff.net>
Date: Apr 20, 2010, 15:10 UTC
Message-ID: <20100420151014.GA11785@coredump.intra.peff.net>
In-Reply-To: <g2u76718491004200752gcf73abf1se05e89bd605e77a@mail.gmail.com>

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

Show 15 quoted lines

> 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.

Show 6 quoted lines

> $ 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