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

Hi,

On Fri, 6 Jul 2007, Daniel Barkalow wrote:

On Fri, 6 Jul 2007, Johannes Schindelin wrote:

quoted

On Fri, 6 Jul 2007, Daniel Barkalow wrote:

quoted

On Fri, 6 Jul 2007, Johannes Schindelin wrote:

quoted

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.

Okay, I misunderstood, then.

Sorry for the noise,
Dscho