On 2009.02.10 06:19:07 -0500, Jeff King wrote:
quoted text
> On Tue, Feb 10, 2009 at 08:52:14AM +0100, Björn Steinbrink wrote:
> 
> > still don't really see what I'd use it for. From what I've heard, some
> > people just consider origin/HEAD a clone artifact without much use, and
> > so far, I think I agree. But maybe there's more to it?
> 
> The ref "origin" will resolve to "refs/remotes/origin/HEAD", if it
> exists. So you can use it as a shorthand for "origin/master" (or
> whatever branch is most interesting to you on the remote).

Yeah, that's what I meant when I said "short-shortname". Maybe it's just
me, but I really can't see myself using that. Would be likely that
"origin" references something else than what I expect, especially when
switching from one repo to another. And doing "git branch -r" to find
out if "origin" is the right thing is slower than just typing the full
shortname right away. Well, just my 2 cents.

quoted text
> > If the <name>/HEAD symref would be created for all remotes and would get
> > updated, that would at least make the marker more meaningful, but I
> 
> It has been noted in the past that it should _not_ be automatically
> updated, since it is really about "what is the user's preference for the
> 'most interesting' branch in this remote". And we don't want to
> overwrite some preference that they specified.

Yeah, as I said in the other mail, having it as a default would make add
-m quite pointless.

quoted text
> So I think it makes sense to:
> 
>   - if it doesn't exist, set it up based on the remote's HEAD. Clone
>     already does this, but "git remote add -f" should probably do it,
>     too. I'm not sure if every fetch should do it.

FWIW, I would hate fetch for doing that. I dislike the whole
<remote>/HEAD thing, and wouldn't want fetch to recreate that for me all
the time.

quoted text
>   - give the user some nice interface (probably via "git remote") to
>     move the pointer around (right now, it is "git symbolic-ref
>     refs/remotes/$remote/HEAD refs/remotes/$remote/$branch").

Maybe "git remote set-master"? Though I kinda dislike the "master" part
of the name, which I just took from the -m option to "remote add",
though. I guess that could increase the confusion about the "master"
branch as pre-setup by "git init" being special, and might lead to
interesting conclusions about that command affecting the remote
repository.

quoted text
>   - give the user some nice interface to re-fetch the remote HEAD and
>     update refs/remotes/$remote/HEAD with it. Probably as an option to
>     the "git remote" invocation above.

Yeah, would make sense.

Björn
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html