On Wed, 21 Jan 2009, Jeff King wrote: > On Wed, Jan 21, 2009 at 02:12:19PM -0500, Jeff King wrote: > > > > I think it might be more appropriate to just care less about a broken > > > symref, explain what's wrong if the user actually tries to use it, and > > > otherwise mostly ignore it. > > > > I thought about that, but I still wonder if deleting it when the > > pointed-to ref is deleted might be more convenient. Remember that > > "refs/remotes/$foo/HEAD" can be accessed by a shorthand "$foo". So that > > means it can impact ref ambiguity lookup. I guess the chance of that > > happening is fairly unlikely, though. > > Not to mention that even without others refs with matching names, it is > probably nicer to the user who does try to access it via "$foo" to > simply say "there is no $foo" rather than a confusing error message > about a deleted branch that they have to manually fix. And that is > easily accomplished by deleting such a bogus symref. I think the ideal thing is to keep the symref as a reminder and just give a non-confusing error message instead of a confusing one. E.g.: """ $foo is set to mean the tracking branch $foo/bar, which does not exist. Use: git remote set-default $foo <name> to set a new default branch for $foo. """ (And, of course, add that subcommand to remote) -Daniel *This .sig left intentionally blank* -- 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
