Re: Deleting the "current" branch in remote bare repositories

On Sun, Feb 08, 2009 at 01:18:02AM +0100, Jan Krüger wrote:

Okay, somehow I missed that. To reiterate the things from that
discussion that I think are most reasonable:

1) a local broken symref should generally be ignored unless we actually
   need the symref.

I think this is almost as easy as:

diff --git a/refs.c b/refs.c
index 024211d..9601101 100644
--- a/refs.c
+++ b/refs.c

@@ -276,7 +276,6 @@ static struct ref_list *get_ref_dir(const char *base, struct ref_list *list)
 				continue;
 			}
 			if (!resolve_ref(ref, sha1, 1, &flag)) {
-				error("%s points nowhere!", ref);
 				continue;
 			}
 			list = add_ref(ref, sha1, flag, list, NULL);

Since this is just called when enumerating all of the loose refs (via
get_loose_refs(), which is generally called from for_each_ref).

However, there is one other complication. rename_ref uses get_loose_refs
to check whether the destination space is available:

  if (!is_refname_available(newref, oldref, get_loose_refs(), 0))
        return 1;

so you can get funny behavior through:

  git branch -m foo bar

when "bar" is a symref pointing to a non-existent ref. Of course, we are
not _changing_ that behavior, since we always just ignored that symref.
But we are removing the warning message that might clue the user that
something confusing is about to happen.

2) there should be a more convenient (porcelain) way to change a
   refs/remotes/foo/HEAD symref, e.g. git remote set-default, possibly
   with an option to re-sync from the remote head (we could even make
   that an option for git remote update).

Yes, I think that is a good idea (optionally with a switch to just
re-grab the information from the remote).

Regarding 2): if we managed to add an option to that to change the
remote HEAD, we could disallow deleting a remote branch that HEAD
points to, and refer to this command. I think the problem is that we
would have to add symref updating logic for all types of remote
protocols.

Yes, the protocol support would make this a much bigger patch (and you
would have to handle the case where the remote side didn't support it).
But bear in mind that deleting the remote HEAD breaks things not just
for you, but for other people who are cloning that remote. Maybe we
should refuse such updates unless "-f" is given (similar to
non-fast-forward updates); I haven't looked to see if we even have the
remote's HEAD information during push, though.

If people agree with these ideas I think I'll write up a couple of
patches to implement these changes. So, any protests?

I say go for it.

-Peff