{"thread":{"id":"8887","subject":"Update local tracking refs when pushing- no way to disable","startedAt":"2007-07-06T00:22:04Z","lastAt":"2007-07-06T19:46:35Z","messageCount":12,"participants":["Dan McGee","Johannes Schindelin","Junio C Hamano","Daniel Barkalow","Marco Costalba","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"46578","messageId":"449c10960707051722q6650ec7dq6012695acdfba4af@mail.gmail.com","threadId":"8887","inReplyTo":null,"subject":"Update local tracking refs when pushing- no way to disable","fromName":"Dan McGee","fromEmail":"dpmcgee@gmail.com","sentAt":"2007-07-06T00:22:04Z","receivedAt":"2007-07-06T00:22:04Z","isPatch":false,"sender":{"key":"dpmcgee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/265817?v=4"},"body":"In this commit:\nb516968ff62ec153e008d033c153affd7ba9ddc6\n\nI don't know if anyone else has the same way of working as I do, but I\ntend to set the \"remote..skipDefaultUpdate\" property to true for\nmy publicly visible repository, just so I don't have duplicate branch\nheads lying around in my local repository. Call this peculiar, but I\nlike it that way. However, git-push does not respect this property,\nmeaning I know have these branches whether I want them or not. In a\ntool such as qgit or even 'git branch -a' output, it starts to get\nawful cluttered.\n\nI'm not terribly familiar with GIT internals, so I don't know that I\nam the best to make a patch for this, but I'll take no response as a\nanswer that I should start coding something up. Please CC me on\nemails, I'm not on the GIT mailing list.\n\n-Dan\n"},{"id":"46581","messageId":"Pine.LNX.4.64.0707060201200.9789@racer.site","threadId":"8887","inReplyTo":"449c10960707051722q6650ec7dq6012695acdfba4af@mail.gmail.com","subject":"Re: Update local tracking refs when pushing- no way to disable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-06T01:17:01Z","receivedAt":"2007-07-06T01:17:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[on this list, it is considered polite to not cull the Cc list anyway]\n\nOn Thu, 5 Jul 2007, Dan McGee wrote:\n\n> In this commit:\n> b516968ff62ec153e008d033c153affd7ba9ddc6\n\nYou might be interested to look only at the changes to builtin-push.c. I \nhave a hunch that you just need to disable setting the remote if \n\"remote..skipDefaultUpdate\" is set.\n\nOf course, for that to work, you would also need to add a member variable \nto struct remote in remote.h, and handle it at the end of handle_config() \nin remote.c.\n\nThen just use remote->skip_default_update in builtin-push.c, to guard \naround lines 90--93.\n\nAs for submitting, please read Documentation/SubmittingPatches first, it \nis not really long, and most of it is obvious.\n\nHth,\nDscho\n"},{"id":"46584","messageId":"7v8x9uiai0.fsf@assigned-by-dhcp.cox.net","threadId":"8887","inReplyTo":"449c10960707051722q6650ec7dq6012695acdfba4af@mail.gmail.com","subject":"Re: Update local tracking refs when pushing- no way to disable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-06T01:31:03Z","receivedAt":"2007-07-06T01:31:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Dan McGee\" writes:\n\n> In this commit:\n> b516968ff62ec153e008d033c153affd7ba9ddc6\n>\n> I don't know if anyone else has the same way of working as I do, but I\n> tend to set the \"remote..skipDefaultUpdate\" property to true for\n> my publicly visible repository, just so I don't have duplicate branch\n> heads lying around in my local repository. Call this peculiar, but I\n> like it that way. However, git-push does not respect this property,\n> meaning I know have these branches whether I want them or not. In a\n> tool such as qgit or even 'git branch -a' output, it starts to get\n> awful cluttered.\n\nActually I do not think git-push nor git-fetch are related to\nwhat that configuration variable tries to control at all. The\nvariable controls what \"git remote update\" does.\n\nDo you fetch from your 'publicly visible repository', and do you\nuse tracking branches for it when you do \"git fetch\" from there?\n\n $ git push my-public\n\nis supposed to pretend that immediately after the push you did\n\"git fetch my-public\" _if_and_only_if_ your \"git fetch\nmy-public\" would fetch the branches you pushed, and you have\nconfigured to store them in .git/refs/remotes/my-public/\n(i.e. your tracking branches). So if you do not fetch from your\nremote and do not have configuration to use tracking branches\nwhen you fetch from there, and if you still see that your push\nupdates your tracking branches, then you found a bug.\n\nBut if you do have configuration to use tracking branches when\nyou fetch from there, that is a different story. I do not think\nthere currently is a way to disable that \"pretend we have\nfetched back immediately\" behaviour. There could be valid\nreasons that you may _want_ to keep your existing tracking\nbranches stale after a push, in which case we may want to make\nit overridable, but at the time that change was accepted, nobody\nhad such a convincing use scenario.\n"},{"id":"46591","messageId":"Pine.LNX.4.64.0707052320090.14638@iabervon.org","threadId":"8887","inReplyTo":"449c10960707051722q6650ec7dq6012695acdfba4af@mail.gmail.com","subject":"Re: Update local tracking refs when pushing- no way to disable","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-07-06T03:37:32Z","receivedAt":"2007-07-06T03:37:32Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 5 Jul 2007, Dan McGee wrote:\n\n> In this commit:\n> b516968ff62ec153e008d033c153affd7ba9ddc6\n> \n> I don't know if anyone else has the same way of working as I do, but I\n> tend to set the \"remote..skipDefaultUpdate\" property to true for\n> my publicly visible repository, just so I don't have duplicate branch\n> heads lying around in my local repository. Call this peculiar, but I\n> like it that way. However, git-push does not respect this property,\n> meaning I know have these branches whether I want them or not. In a\n> tool such as qgit or even 'git branch -a' output, it starts to get\n> awful cluttered.\n\nWhat git-fetch and git-push care about is whether you have an entry \n\"remote..fetch\" with a colon and stuff on the right of it. If so, \nthis is a pattern that is used to generate the duplicate branch heads that \nyou don't want. git clone sets it up to a default pattern \n(refs/remotes/origin/*), and I don't think there's any way to make it not \ndo that, but you can just reconfigure it afterwards if you don't like it.\n\nI can't see where git-push would get the names to use if you don't have \nsuch an entry, and having the entry isn't useful if you actually don't \nwant those refs. It's probably just a matter of deleting it, since it was \nprobably created for you by some tool trying to be helpful.\n\n(AFAICT, the only additional stuff that -a shows with git branch is the \nstuff that you're deleting; perhaps qgit should have an option to not show \nremotes, or not show them by default or only show them if what they point \nto isn't otherwise marked? Anyway, it shouldn't be necessary to avoid \nhaving this information just so that it isn't shown in interfaces you \nuse.)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"46603","messageId":"e5bfff550707060126t781587aaxbe2f6eca1c282985@mail.gmail.com","threadId":"8887","inReplyTo":"Pine.LNX.4.64.0707052320090.14638@iabervon.org","subject":"Re: Update local tracking refs when pushing- no way to disable","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-06T08:26:32Z","receivedAt":"2007-07-06T08:26:32Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/6/07, Daniel Barkalow wrote:\n>\n> (AFAICT, the only additional stuff that -a shows with git branch is the\n> stuff that you're deleting; perhaps qgit should have an option to not show\n> remotes, or not show them by default or only show them if what they point\n> to isn't otherwise marked? Anyway, it shouldn't be necessary to avoid\n> having this information just so that it isn't shown in interfaces you\n> use.)\n>\n\nProbably an option \"show remote branches\" from a popup context menu\n(right click) is the more natural and predictable solution.\n\nIn case someone is interested, please confirm me, I will add that.\n\nMarco\n"},{"id":"46607","messageId":"20070706084241.GC16319@spearce.org","threadId":"8887","inReplyTo":"e5bfff550707060126t781587aaxbe2f6eca1c282985@mail.gmail.com","subject":"Re: Update local tracking refs when pushing- no way to disable","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-06T08:42:41Z","receivedAt":"2007-07-06T08:42:41Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Marco Costalba wrote:\n> On 7/6/07, Daniel Barkalow wrote:\n> >\n> >(AFAICT, the only additional stuff that -a shows with git branch is the\n> >stuff that you're deleting; perhaps qgit should have an option to not show\n> >remotes, or not show them by default or only show them if what they point\n> >to isn't otherwise marked? Anyway, it shouldn't be necessary to avoid\n> >having this information just so that it isn't shown in interfaces you\n> >use.)\n> >\n> \n> Probably an option \"show remote branches\" from a popup context menu\n> (right click) is the more natural and predictable solution.\n\nRecently I was faced with handling a repository that has over\n200 local refs/heads and 200+ refs/remotes that the user might\nbe interested in working on. Yea, its fun to look at in gitk.\nIt is not fun to run `git fetch` when on Cygwin.\n\nAnyway, the git-gui `pu` branch now has new UI to handle these\nsorts of cases rather nicely. The revision selection mega-widget\nthat I recently wrote lets the user select which \"class\" of ref\n(head, tracking branch, tag) they want and then filter them using\na substring glob filter. The trick works very well to let the user\nweed the list of 400+ possible refs down to just a couple that they\ncan pick from with the keyboard, or the mouse.\n\nThe UI will be in 0.8.0. Which I'm hoping to go into an rc status\nlater this week.\n\n\nMinor warning: currently the `pu` branch of git-gui probably\nrequires git 1.5.3-rc0 or later. It doesn't test for it and just\nassumes your git is new enough. I do plan on fixing the couple of\nspots that might matter to be conditional and fallback gracefully\nif 1.5.3 isn't available. Just haven't done it yet. Those will\nbe fixed before they merge to `master`.\n\n-- \nShawn.\n"},{"id":"46620","messageId":"Pine.LNX.4.64.0707061340350.4093@racer.site","threadId":"8887","inReplyTo":"Pine.LNX.4.64.0707052320090.14638@iabervon.org","subject":"Re: Update local tracking refs when pushing- no way to disable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-06T12:46:34Z","receivedAt":"2007-07-06T12:46:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 5 Jul 2007, Daniel Barkalow wrote:\n\n> What git-fetch and git-push care about is whether you have an entry \n> \"remote..fetch\" with a colon and stuff on the right of it. If so, \n> this is a pattern that is used to generate the duplicate branch heads \n> that you don't want. git clone sets it up to a default pattern \n> (refs/remotes/origin/*), and I don't think there's any way to make it \n> not do that, but you can just reconfigure it afterwards if you don't \n> like it.\n\nRelated, but not identical, is the problem illustrated in \nhttp://thread.gmane.org/gmane.comp.version-control.git/49888\n\nIMHO there is a bug. IIUC git push first looks for common ref names on the \nlocal and remote side (yes, refs/remotes are excluded since v1.5.3-rc0~9, \nbut the underlying problem is still there). Then it pushes them. But here, \nsomething seems to have gone wrong: refs/remotes/origin/HEAD is a symref. \nAnd the corresponding ref is updated. Should git-push not just _not_ \nupdate symrefs?\n\nCiao,\nDscho\n"},{"id":"46622","messageId":"449c10960707060620t3538b6d7w3e9cba50eaa0e369@mail.gmail.com","threadId":"8887","inReplyTo":"Pine.LNX.4.64.0707052320090.14638@iabervon.org","subject":"Re: Update local tracking refs when pushing- no way to disable","fromName":"Dan McGee","fromEmail":"dpmcgee@gmail.com","sentAt":"2007-07-06T13:20:02Z","receivedAt":"2007-07-06T13:20:02Z","isPatch":false,"sender":{"key":"dpmcgee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/265817?v=4"},"body":"On 7/5/07, Daniel Barkalow wrote:\n> On Thu, 5 Jul 2007, Dan McGee wrote:\n>\n> > In this commit:\n> > b516968ff62ec153e008d033c153affd7ba9ddc6\n> >\n> > I don't know if anyone else has the same way of working as I do, but I\n> > tend to set the \"remote..skipDefaultUpdate\" property to true for\n> > my publicly visible repository, just so I don't have duplicate branch\n> > heads lying around in my local repository. Call this peculiar, but I\n> > like it that way. However, git-push does not respect this property,\n> > meaning I know have these branches whether I want them or not. In a\n> > tool such as qgit or even 'git branch -a' output, it starts to get\n> > awful cluttered.\n>\n> What git-fetch and git-push care about is whether you have an entry\n> \"remote..fetch\" with a colon and stuff on the right of it. If so,\n> this is a pattern that is used to generate the duplicate branch heads that\n> you don't want. git clone sets it up to a default pattern\n> (refs/remotes/origin/*), and I don't think there's any way to make it not\n> do that, but you can just reconfigure it afterwards if you don't like it.\n\nWow, my bad here on this one. Didn't even think about the default config line:\n[remote \"toofishes.net\"]\n url = toofishes.net:~/gitprojects/shoepolish.git/\n fetch = +refs/heads/*:refs/remotes/toofishes.net/*\n push = +refs/heads/*:refs/heads/*\n\nGetting rid of that fetch line makes it work as intended. And not to\nhijack my own thread, but did behavior change between 1.5.2.3 and\n1.5.3 wrt non-subset pushes?\n\n$ git push toofishes.net\nerror: remote 'refs/heads/alpm_list_speed' is not a strict subset of\nlocal ref 'refs/heads/alpm_list_speed'. maybe you are not up-to-date\nand need to pull first?\nerror: remote 'refs/heads/asciidoc' is not a strict subset of local\nref 'refs/heads/asciidoc'. maybe you are not up-to-date and need to\npull first?\nerror: remote 'refs/heads/color' is not a strict subset of local ref\n'refs/heads/color'. maybe you are not up-to-date and need to pull\nfirst?\nerror: remote 'refs/heads/permissions' is not a strict subset of local\nref 'refs/heads/permissions'. maybe you are not up-to-date and need to\npull first?\nerror: remote 'refs/heads/pkgname_check' is not a strict subset of\nlocal ref 'refs/heads/pkgname_check'. maybe you are not up-to-date and\nneed to pull first?\nupdating 'refs/heads/working'\n from 59d9ccf48d84fd1e59f78cb4dcf428e53d1c6911\n to 6b7b9743181078aa7152daffdfc1eaeb46304c0f\nGenerating pack...\nDone counting 0 objects.\nWriting 0 objects...\nTotal 0 (delta 0), reused 0 (delta 0)\nrefs/heads/working: 59d9ccf48d84fd1e59f78cb4dcf428e53d1c6911 ->\n6b7b9743181078aa7152daffdfc1eaeb46304c0f\n\nI thought the '+' sign in the push refspec would supress these errors,\nbut it doesn't seem to. Running 'git push -f' works but that was never\nnecessary before after doing some rebasing of these branches.\n\n-Dan\n"},{"id":"46653","messageId":"Pine.LNX.4.64.0707061440050.14638@iabervon.org","threadId":"8887","inReplyTo":"Pine.LNX.4.64.0707061340350.4093@racer.site","subject":"Re: Update local tracking refs when pushing- no way to disable","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-07-06T18:56:00Z","receivedAt":"2007-07-06T18:56:00Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 6 Jul 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> Related, but not identical, is the problem illustrated in \n> http://thread.gmane.org/gmane.comp.version-control.git/49888\n> \n> IMHO there is a bug. IIUC git push first looks for common ref names on the \n> local and remote side (yes, refs/remotes are excluded since v1.5.3-rc0~9, \n> but the underlying problem is still there). Then it pushes them. But here, \n> something seems to have gone wrong: refs/remotes/origin/HEAD is a symref. \n> And the corresponding ref is updated. Should git-push not just _not_ \n> update symrefs?\n\nI believe this actually have nothing to do with git-push; it's actually \ngit-receive-pack and maybe git-send-pack. Probably git-receive-pack \nshouldn't list symrefs at all, or should somehow report them as links so \nthat they can be compared as links. The only refs that git-push itself \nupdates are tracking refs on the local side for refs on the remote side \nwhich were updated. In the report, the reporter had (obviously) not \nconfigured any local tracking refs for the remote's tracking refs.\n\nNow, if there are symref heads on the remote (maybe somebody wants to have \na \"dominus\" branch which is a symref to \"master\" for people who only speak \nLatin), and this was in tracking refs as a symref as well, and the user \npushed to both (with the remote side somehow identifying that the same \nchange is being made to both names, and that's okay), then the tracking \nrefs would need this same logic as well. But that requires an \nunimplemented and unrequested feature, with fixes in a number of other \nplaces first, before it's even possible to have git-push need to worry \nabout it.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"46654","messageId":"Pine.LNX.4.64.0707061958540.4093@racer.site","threadId":"8887","inReplyTo":"Pine.LNX.4.64.0707061440050.14638@iabervon.org","subject":"Re: Update local tracking refs when pushing- no way to disable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-06T18:59:58Z","receivedAt":"2007-07-06T18:59:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 6 Jul 2007, Daniel Barkalow wrote:\n\n> On Fri, 6 Jul 2007, Johannes Schindelin wrote:\n> \n> > Related, but not identical, is the problem illustrated in \n> > http://thread.gmane.org/gmane.comp.version-control.git/49888\n> > \n> > IMHO there is a bug. IIUC git push first looks for common ref names on \n> > the local and remote side (yes, refs/remotes are excluded since \n> > v1.5.3-rc0~9, but the underlying problem is still there). Then it \n> > pushes them. But here, something seems to have gone wrong: \n> > refs/remotes/origin/HEAD is a symref. And the corresponding ref is \n> > updated. Should git-push not just _not_ update symrefs?\n> \n> I believe this actually have nothing to do with git-push; it's actually \n> git-receive-pack and maybe git-send-pack. Probably git-receive-pack \n> shouldn't list symrefs at all, or should somehow report them as links so \n> that they can be compared as links. The only refs that git-push itself \n> updates are tracking refs on the local side for refs on the remote side \n> which were updated. In the report, the reporter had (obviously) not \n> configured any local tracking refs for the remote's tracking refs.\n\nSorry, I think I did not make myself clear. The updates refs were _local_ \nrefs. And they _were_ symrefs.\n\nCiao,\nDscho\n"},{"id":"46655","messageId":"Pine.LNX.4.64.0707061514090.6977@iabervon.org","threadId":"8887","inReplyTo":"Pine.LNX.4.64.0707061958540.4093@racer.site","subject":"Re: Update local tracking refs when pushing- no way to disable","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-07-06T19:20:29Z","receivedAt":"2007-07-06T19:20:29Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 6 Jul 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Fri, 6 Jul 2007, Daniel Barkalow wrote:\n> \n> > On Fri, 6 Jul 2007, Johannes Schindelin wrote:\n> > \n> > > Related, but not identical, is the problem illustrated in \n> > > http://thread.gmane.org/gmane.comp.version-control.git/49888\n> > > \n> > > IMHO there is a bug. IIUC git push first looks for common ref names on \n> > > the local and remote side (yes, refs/remotes are excluded since \n> > > v1.5.3-rc0~9, but the underlying problem is still there). Then it \n> > > pushes them. But here, something seems to have gone wrong: \n> > > refs/remotes/origin/HEAD is a symref. And the corresponding ref is \n> > > updated. Should git-push not just _not_ update symrefs?\n> > \n> > I believe this actually have nothing to do with git-push; it's actually \n> > git-receive-pack and maybe git-send-pack. Probably git-receive-pack \n> > shouldn't list symrefs at all, or should somehow report them as links so \n> > that they can be compared as links. The only refs that git-push itself \n> > updates are tracking refs on the local side for refs on the remote side \n> > which were updated. In the report, the reporter had (obviously) not \n> > configured any local tracking refs for the remote's tracking refs.\n> \n> Sorry, I think I did not make myself clear. The updates refs were _local_ \n> refs. And they _were_ symrefs.\n\nNo, no local refs were updated. This would have given the message \"Also \nlocal refs/remotes/origin/HEAD\", which wasn't there. What was updated was \ntracking refs on the remote (which were created as local tracking refs \nwhen somebody was running git commands local to the repository which, for \nthe failing command, was remote). The logic for updating local refs on a \npush was not used at all in this case, according to the output in the \nmessage you linked to.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"46656","messageId":"Pine.LNX.4.64.0707062044210.4093@racer.site","threadId":"8887","inReplyTo":"Pine.LNX.4.64.0707061514090.6977@iabervon.org","subject":"Re: Update local tracking refs when pushing- no way to disable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-06T19:46:35Z","receivedAt":"2007-07-06T19:46:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 6 Jul 2007, Daniel Barkalow wrote:\n\n> On Fri, 6 Jul 2007, Johannes Schindelin wrote:\n> \n> > On Fri, 6 Jul 2007, Daniel Barkalow wrote:\n> > \n> > > On Fri, 6 Jul 2007, Johannes Schindelin wrote:\n> > > \n> > > > Related, but not identical, is the problem illustrated in \n> > > > http://thread.gmane.org/gmane.comp.version-control.git/49888\n> > > > \n> > > > IMHO there is a bug. IIUC git push first looks for common ref \n> > > > names on the local and remote side (yes, refs/remotes are excluded \n> > > > since v1.5.3-rc0~9, but the underlying problem is still there). \n> > > > Then it pushes them. But here, something seems to have gone wrong: \n> > > > refs/remotes/origin/HEAD is a symref. And the corresponding ref is \n> > > > updated. Should git-push not just _not_ update symrefs?\n> > > \n> > > I believe this actually have nothing to do with git-push; it's \n> > > actually git-receive-pack and maybe git-send-pack. Probably \n> > > git-receive-pack shouldn't list symrefs at all, or should somehow \n> > > report them as links so that they can be compared as links. The only \n> > > refs that git-push itself updates are tracking refs on the local \n> > > side for refs on the remote side which were updated. In the report, \n> > > the reporter had (obviously) not configured any local tracking refs \n> > > for the remote's tracking refs.\n> > \n> > Sorry, I think I did not make myself clear. The updates refs were \n> > _local_ refs. And they _were_ symrefs.\n> \n> No, no local refs were updated. This would have given the message \"Also \n> local refs/remotes/origin/HEAD\", which wasn't there. What was updated \n> was tracking refs on the remote (which were created as local tracking \n> refs when somebody was running git commands local to the repository \n> which, for the failing command, was remote). The logic for updating \n> local refs on a push was not used at all in this case, according to the \n> output in the message you linked to.\n\nOkay, I misunderstood, then.\n\nSorry for the noise,\nDscho\n"}]}