Hi, On Fri, 6 Jul 2007, Daniel Barkalow wrote: > 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. Okay, I misunderstood, then. Sorry for the noise, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
