Re: [PATCH 4/4] builtin-remote: add set-head verb

[Jay Soffian <jaysoffian@gmail.com>]

On Fri, Feb 13, 2009 at 9:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I do not care too deeply if an explicit request to "set-head --auto"
> screws up and sets a HEAD that was pointing at the right branch to another
> branch because the command is not taught to give preference to the branch
> HEAD originally points at

So I don't mind fixing this, but here's the thing.

Say user has refs/remotes/origin/HEAD set to frotz. They then run "git
show remote origin" and we see that HEAD on the remote end could be
either master or frotz (both have the same SHA1).

What should we show in the output of "git remote show origin" next to
the HEAD line? master, or frotz? If we show master, then user might
wonder why "git remote set-head origin --auto" leaves
refs/remotes/origin/HEAD set to frotz. If we show frotz, then user
might wonder why when they cloned the repo in the first place they
ended up with HEAD set to master.

I'm bothered by that inconsistency, which is why I didn't follow-up
with another patch immediately.

But I will propose an alternative. In the output of "get remote show
origin", we show all matching branches. If the user does a set-head
--auto and we cannot determine HEAD unambiguously, we do something
like:

$ git remote set-head origin --auto
error: Multiple branches match HEAD. Please choose one explicitly with:
   git remote set-head origin master
   git remote set-head origin frotz

Hmm?

j.