Johannes Schindelin wrote:
quoted text
> Hi,
> 
> On Mon, 22 Oct 2007, Andreas Ericsson wrote:
> 
>> If I were to suggest any improvements, it'd be to change the semantics of
>> git-pull to always update the local branches set up to be merged with the
>> remote tracking branches when they, prior to fetching, pointed to the same
>> commit, such that when
>>
>> $ git show-ref master
>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master
>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master
>>
>> refs/heads/master gets set to refs/remotes/origin/master post-fetch.
> 
> In general, this should fail.  Because you are expected to have local 
> changes in the local branches.


BS argument. Git knows when I haven't got any changes on my local 
branches, and it can be fairly safely assumed that when I feel like 
making any, I'd like to make them off as fresh a tip as possible unless 
I explicitly tell git otherwise.

Nice hint though. I'm working on a patch for it now but I've only looked 
at it 15 minutes over lunch today, so it'll probably be a few days.


quoted text
>  What you describe suggests that you should 
> not use the branch name "master" at all, but "origin/master".
> 

No. I want the ability to commit locally without it affecting my 
upstream tracking branches, but I also want to make sure that when I 
want to work on some branch I don't frequently touch, git will make sure 
it's kept up-to-speed with the branch I explicitly have told it to merge 
with, without me having to remember if I was on that branch when I last 
did git-pull (I might not have a network connection), and without having 
to remember what I decided to call my locally-modifiable branch.


quoted text
> That said, there is a pretty simple way to achieve what you want (even if 
> it does not help the confusion you create between local and remote 
> branches):
> 
> 	git config --add remote.origin.fetch master:master
> 
> Of course, when you checkout "master" and pull then, you'll get even more 
> problems, _exactly_ because you muddled up the clear distinction between 
> local and remote branches.
> 

That's not what I want at all. I must have been unclear in my original 
post. I'm talking about git doing automatically what every single user 
I've ever talked to wants it to do, which is to maintain the state of 
sync that the "local-and-modifiable" branches had with the 
"local-non-modifiable-aka-remote-tracking" branches. Note that the state 
of sync is more important to users than git never ever touching the 
branches that they *could* have (but don't have) changes on.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
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