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

From: Jay Soffian <jaysoffian@gmail.com>
Date: Feb 14, 2009, 02:59 UTC
Message-ID: <76718490902131859u4645dc62h79632cb20ee90d69@mail.gmail.com>
In-Reply-To: <7vab8p4w1u.fsf@gitster.siamese.dyndns.org>

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.