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

[Junio C Hamano <gitster@pobox.com>]

"Jan Krüger" <jk@jk.gs> writes:

> 1) a local broken symref should generally be ignored unless we actually
>    need the symref.
>
> 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).

It would be good to sugarcoat symbolic-ref with "git remote set-something",
although I am not sure "default" is a good term for it (it feels more
like "primary" to me).

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

With (2), you would have the ability to pick the branch you are the most
interested in among the branches that particular remote 'foo' offers,
which is what remotes/foo/HEAD is about.  But the latter part of your
sentence is talking about disallowing the removal of a branch in the
remote 'foo'.  How would (2) help you if what you want is to delete one
particular branch at the remote 'foo'?  I do not think these two are
related at all.

Rather, if you reject deletion of the current branch at the remote, you
would not get into the situation where your remote/foo/HEAD points at
nonexisting tracking branch by your own "deleting the branch by pushing a
void to the remote", and you would reduce the need for (2).

I said "reduce" because you can get into the same situation by other
means.  For example, somebody else can remove the branch your
remotes/foo/HEAD points at.  Or the repository owner of the remote can say
"my HEAD is not 'master' anymore, it is 'next'" and delete 'master' from
there.  In either case, your next "git remote prune foo" will get you into
that situation, and you would need (2) to recover (or use symbolic-ref).

Forbidding the deletion of the current branch at remote and (2) do not
have anything to do with each other.

I think forbidding the removal of the current branch falls into the same
category as forbidding the updating of the current branch.  It is what you
would want to avoid in many workflows, and receive.denyDeleteCurrent that
defaults to refuse may eventually be a good way to do this, but we need a
transition plan for that escape hatch.  Most people may not see why they
would want to do such a thing, and many people may perceive that in *their
own* workflow such an operation can only be a mistake, but that is not a
good enough reason to suddenly start forbidding something other people
were allowed to do so far.

The "refer to this command" you mention can and should be issued when the
user actually uses "remotes/foo" (or "remotes/foo/HEAD"), expecting it to
resolve to the branch HEAD used to point at but now missing.  The current
errors you see in your issue (1) were *meant to* notify you of the
situation as soon as it occurs (i.e. it gives pre-emptive warning, even
before you actually refer to "remotes/foo/HEAD"), expecting that you know
what to do (namely, repoint HEAD with symbolic-ref, or remove HEAD), so
theoretically you could also issue the "refer to this command" there as
well.

But I agree the current error messages are a bit too loud, and it would be
better to squelch them and only give the instruction when the user refers
to "remotes/foo" or "remotes/foo/HEAD".