From: Jeff King Date: Tue, 20 Apr 2010 15:10:14 GMT Subject: Re: ghost refs Message-ID: <20100420151014.GA11785@coredump.intra.peff.net> In-Reply-To: On Tue, Apr 20, 2010 at 10:52:42AM -0400, Jay Soffian wrote: > On Tue, Apr 20, 2010 at 10:24 AM, Jeff King 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