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@xxxxxxxx> 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 -- 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