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