"Jan Krüger" <jk@xxxxx> 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". -- 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
