Junio C Hamano <gitster@xxxxxxxxx> writes: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> I don't see how it's fundimentally different than the DWIM logic of >> taking "<name>" and seeing that there's only one "refs/heads/<name>", >> and giving up in other cases where we get ambiguous reference names that >> we can't resolve. > > In that example, once you obtained a local branch whose name is > <name>, it is obvious how you would work with that. Your next "git > checkout <name>" would work on the local one, and only the initial > one does something magical. > > Which makes quite a lot of sense. > > There is no similarity in it with "--to-branch <tag>" that is being > discussed here. Another thing you seem to be ignoring is that it requires you to prepare in advance and keep one (and only one) dormant branch for the <tag> you will use the "--to-branch <tag>" with, because it finds the branch whose tip exactly points at the tag. You can use the command exactly once for the <tag> and check out that branch, but then what? Once you start working on that branch, you would by definition no longer have a suitable branch that can be used to with "--to-branch <tag>", because (1) it was the only one that pointed at <tag> or you'd have gotten an error, and (2) you have moved the tip of the branch so it no longer points at the tag. And you'd expect the user to say "git branch <next-branch> <tag>" in preparation for the next time you might want to use "--to-branch <tag>" and keep that pristine? I do not think of any similar counterpart in "teach checkout <name> to dwim and fork from a remote-tracking branch from a remote, if there is no other remote with a branch with that name" DWIMming to these nonsense.
