On Thu, 8 Feb 2007, Bill Lear wrote:

quoted text
>

> However, I still have a few open issues with the other branch of this

> discussion, i.e., why can we not have an update operation that

> respects branches in the first place, as 'git pull' seems to do, when

> run from the master branch?

Actually, git does that all correctly for other branches too, but only in

git-1.5.
It's one of the bigger UI warts that got fixed since the last release

(although it got fixed by better config management, and as such you'll

only *see* the fixes if you end up doing the initial clone with the new

git version - if you use a new git version with an old repo, many - but

not all - bad semantics will remain).
Considering how stable the -rc kernels are (and actually, git "master" in

general), there's really very little reason to wait for the real release.

Junio has been very careful, and I think a lot of the delay in 1.5 has

been about trying to get all the new stuff that changes semantics subtly

in before the release, so that Junio will not have to do any real user-

visible changes later.
So it might be worth while trying out git-1.5.0-rc4, and seeing if that

solves some of the UI issues for you guys. It changes things like where

the default remote branches are, and makes the distinction between "my

local copy of branch X" and "the remote branch X" much clearer, which has

clearly been a UI problem.
			Linus

-

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