Re: Update local tracking refs when pushing- no way to disable

> On Fri, 6 Jul 2007, Johannes Schindelin wrote:
> 
> > On Fri, 6 Jul 2007, Daniel Barkalow wrote:
> > 
> > > On Fri, 6 Jul 2007, Johannes Schindelin wrote:
> > > 
> > > > Related, but not identical, is the problem illustrated in 
> > > > http://thread.gmane.org/gmane.comp.version-control.git/49888
> > > > 
> > > > IMHO there is a bug. IIUC git push first looks for common ref 
> > > > names on the local and remote side (yes, refs/remotes are excluded 
> > > > since v1.5.3-rc0~9, but the underlying problem is still there). 
> > > > Then it pushes them. But here, something seems to have gone wrong: 
> > > > refs/remotes/origin/HEAD is a symref. And the corresponding ref is 
> > > > updated. Should git-push not just _not_ update symrefs?
> > > 
> > > I believe this actually have nothing to do with git-push; it's 
> > > actually git-receive-pack and maybe git-send-pack. Probably 
> > > git-receive-pack shouldn't list symrefs at all, or should somehow 
> > > report them as links so that they can be compared as links. The only 
> > > refs that git-push itself updates are tracking refs on the local 
> > > side for refs on the remote side which were updated. In the report, 
> > > the reporter had (obviously) not configured any local tracking refs 
> > > for the remote's tracking refs.
> > 
> > Sorry, I think I did not make myself clear. The updates refs were 
> > _local_ refs. And they _were_ symrefs.
> 
> No, no local refs were updated. This would have given the message "Also 
> local refs/remotes/origin/HEAD", which wasn't there. What was updated 
> was tracking refs on the remote (which were created as local tracking 
> refs when somebody was running git commands local to the repository 
> which, for the failing command, was remote). The logic for updating 
> local refs on a push was not used at all in this case, according to the 
> output in the message you linked to.