{"thread":{"id":"21481","subject":"Automatically remote prune","startedAt":"2009-11-04T10:42:52Z","lastAt":"2009-11-08T19:08:18Z","messageCount":15,"participants":["John Tapsell","Junio C Hamano","Shawn O. Pearce","Sitaram Chamarty","Dmitry Potapov","Jay Soffian","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"126749","messageId":"43d8ce650911040242l44bbf87dm35494e04ce9039aa@mail.gmail.com","threadId":"21481","inReplyTo":null,"subject":"Automatically remote prune","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-11-04T10:42:52Z","receivedAt":"2009-11-04T10:42:52Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"Hi all,\n\n Is there any particular reason why \"git update\" doesn't\nautomatically remove remote branches that have been removed on the\nserver? I keep getting questions about this from confused users.\n\n If there's strong resistance against that (there usually is for\nchanging any default behaviour), could we at least mark deleted\nbranches?\nSo maybe:\n\n$> git branch -r\norigin/blah1 [Deleted]\norigin/blah2\n\n(Some branches have been deleted on the remote server. Use \"git\nremote prune origin\" to remove these)\n\nOr something.\n\nJohn\n"},{"id":"126783","messageId":"7v639qi2un.fsf@alter.siamese.dyndns.org","threadId":"21481","inReplyTo":"43d8ce650911040242l44bbf87dm35494e04ce9039aa@mail.gmail.com","subject":"Re: Automatically remote prune","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-04T18:04:00Z","receivedAt":"2009-11-04T18:04:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Tapsell writes:\n\n> $> git branch -r\n> origin/blah1 [Deleted]\n> origin/blah2\n>\n> (Some branches have been deleted on the remote server. Use \"git\n> remote prune origin\" to remove these)\n\nThere is no information locally available to do this, unless you are\nwilling to contact the remote every time somebody says \"branch -r\" (or\n\"branch -a\"). I tend to think it is not very nice for the branch command\nthat has long been a \"local\" command to suddenly start talking to outside\nworld.\n\nYou could store necessary information somewhere else when you contacted\nthe remote the last time, but we need to consider what the benefits are to\ngive this information in the first place.a\n\nThe [Deleted] mark in your suggestion tells the user:\n\n This is already removed in the remote, and this tracking copy is the\n only way for you to view it ever again. Do not run 'remote prune\n origin' blindly otherwise you will lose it.\n\nBut that is already possible with \"git remote show origin\", isn't it?\n"},{"id":"126866","messageId":"43d8ce650911041741w4b39d137ha2a1529a15256d27@mail.gmail.com","threadId":"21481","inReplyTo":"7v639qi2un.fsf@alter.siamese.dyndns.org","subject":"Re: Automatically remote prune","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-11-05T01:41:26Z","receivedAt":"2009-11-05T01:41:26Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/11/5 Junio C Hamano :\n> John Tapsell writes:\n\n> You could store necessary information somewhere else when you contacted\n> the remote the last time, but we need to consider what the benefits are to\n> give this information in the first place.\n\nWe already get all this information on a \"git fetch\", no? And then\npromptly discard it. Surely when we do \"git fetch\" . So I'm talking\nabout just not ignoring the information we get from git fetch, but\npresent that information to the user.\n\nJohn\n"},{"id":"126868","messageId":"20091105020019.GL10505@spearce.org","threadId":"21481","inReplyTo":"43d8ce650911041741w4b39d137ha2a1529a15256d27@mail.gmail.com","subject":"Re: Automatically remote prune","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-11-05T02:00:19Z","receivedAt":"2009-11-05T02:00:19Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"John Tapsell wrote:\n> 2009/11/5 Junio C Hamano :\n> > John Tapsell writes:\n> \n> > You could store necessary information somewhere else when you contacted\n> > the remote the last time, but we need to consider what the benefits are to\n> > give this information in the first place.\n> \n> We already get all this information on a \"git fetch\", no? And then\n> promptly discard it. Surely when we do \"git fetch\" . So I'm talking\n> about just not ignoring the information we get from git fetch, but\n> present that information to the user.\n\nGood point. We currently don't have a provision to store this\ninformation, but we could store a list of dead remote tracking\nbranches for reference later during `git branch -r`.\n\nIts not a lot of data, it just has little perceived value to most\nGit hackers because a remote branch disappears very infrequently\n(if ever) for most of us.\n\n-- \nShawn.\n"},{"id":"126870","messageId":"7viqdpemki.fsf@alter.siamese.dyndns.org","threadId":"21481","inReplyTo":"43d8ce650911041741w4b39d137ha2a1529a15256d27@mail.gmail.com","subject":"Re: Automatically remote prune","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-05T02:23:57Z","receivedAt":"2009-11-05T02:23:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Tapsell writes:\n\n> 2009/11/5 Junio C Hamano :\n>> John Tapsell writes:\n>\n>> You could store necessary information somewhere else when you contacted\n>> the remote the last time, but we need to consider what the benefits are to\n>> give this information in the first place.\n>\n> We already get all this information on a \"git fetch\", no?\n\n\"what the benefits are to give this information _in the 'branch' output_\"\nwas what I meant. From the part you omitted from my message:\n\n The [Deleted] mark in your suggestion tells the user:\n\n This is already removed in the remote, and this tracking copy is the\n only way for you to view it ever again. Do not run 'remote prune\n origin' blindly otherwise you will lose it.\n\nThere are two reasons I could think of that the user might want to know\nthis.\n\n (1) The user wants to keep the remotes//* namespace clean (iow,\n the user does not care to keep old commits that were deemed bad by\n the remote side) by removing stale tracking refs. But in this case,\n it is very unlikely that the user would use \"git branch -d -r\" to\n remove stale ones one-by-one after seeing '[Deleted]' label in the\n output from \"git branch -r\". Rather he would run \"git remote prune\n origin\" to blindly remove them all.\n\n (2) The user does want to be careful not to lose commits that now only\n exists in his repository. Perhaps he saw something worthwhile to\n base his topic later on. But these stale remote tracking refs are\n not removed until the user runs \"git remote prune origin\". As long\n as we give him a way to check what will be pruned before running \"git\n remote prune\", there is not much point in showing that information in\n output of \"git branch -r\". There is no need to keep extra info by\n creating a new file in .git by \"fetch\". Nor showing that to the user\n when he does \"fetch\" either, for that matter.\n\nA better approach to please the first class of audience may be to\nintroduce an option that tells fetch to cull tracking refs that are stale.\nThen \"branch -r\" output will not show stale refs and there is no place\n(nor need) to show [Deleted] labels.\n\nSuch an option won't be very useful for the second class of audience,\nthough. For them we would need something else, and it would likely be an\nenhancement to \"git remote\". It would ask the other side what refs are no\nlonger there, and then check our local refspace to see if there are local\ntopics based on them (which would mean the user is already in a trouble)\nand which ones are not forked locally at all (which may mean \"it wasn't\ninteresting to the user, and we can safely remove it\" or \"the user was\ninterested in it, but hasn't got around to forking from it yet, being busy\nworking on something else\"). I am unsure what should be done in the\nlatter case (i.e. lost remote refs haven't been touched locally) but am\njust thinking aloud.\n"},{"id":"126872","messageId":"2e24e5b90911041915o40922167ob48a8503ee262b37@mail.gmail.com","threadId":"21481","inReplyTo":"7viqdpemki.fsf@alter.siamese.dyndns.org","subject":"Re: Automatically remote prune","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-11-05T03:15:41Z","receivedAt":"2009-11-05T03:15:41Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Thu, Nov 5, 2009 at 7:53 AM, Junio C Hamano wrote:\n\n>  (1) The user wants to keep the remotes//* namespace clean (iow,\n\n[snip]\n\n>  (2) The user does want to be careful not to lose commits that now only\n\nThis whole discussion is a conflict between those two. The current\nsystem does the latter, safer, thing. John's users are getting\nconfused because they *think* this means the remote still has those\nrefs.\n\nAt best an alias that does a prune before (or after) a fetch should do.\n\nAnd I notice 'git gui' has an option to \"prune during fetch\" -- maybe\nthat should be an option that is also made available to the CLI fetch.\n"},{"id":"126888","messageId":"43d8ce650911050005l6d120cb0h374f3c04b3948b25@mail.gmail.com","threadId":"21481","inReplyTo":"7viqdpemki.fsf@alter.siamese.dyndns.org","subject":"Re: Automatically remote prune","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-11-05T08:05:50Z","receivedAt":"2009-11-05T08:05:50Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/11/5 Junio C Hamano :\n> John Tapsell writes:\n> \"what the benefits are to give this information _in the 'branch' output_\"\n> was what I meant.  From the part you omitted from my message:\n\nI omitted it just because, imho, it's not what I 'care about'. I'm\nnot trying to help advanced users (Users that _want_ to keep\nremotes/origin/* clean and users that _want_ to be careful to not lose\ncommits are both advanced users, imho). I'm just interested in\nreducing confusion for non-advanced users. So either not-showing\nremoved remote branches by default, or showing them but marking them\nas deleted.\n\n> A better approach to please the first class of audience may be to\n> introduce an option that tells fetch to cull tracking refs that are stale.\n> Then \"branch -r\" output will not show stale refs and there is no place\n> (nor need) to show [Deleted] labels.\n\nIf it's a non-default option, then it won't help the non-advanced users.\n\n> Such an option won't be very useful for the second class of audience,\n> though.  For them we would need something else, and it would likely be an\n> enhancement to \"git remote\".\n\nWhich still leaves confusion when viewing \"git branch -r\" since they\nwould show up there still.\n\n\nJohn\n"},{"id":"126905","messageId":"20091105131940.GF27126@dpotapov.dyndns.org","threadId":"21481","inReplyTo":"7viqdpemki.fsf@alter.siamese.dyndns.org","subject":"Re: Automatically remote prune","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-11-05T13:19:40Z","receivedAt":"2009-11-05T13:19:40Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Nov 04, 2009 at 06:23:57PM -0800, Junio C Hamano wrote:\n> \n> There are two reasons I could think of that the user might want to know\n> this.\n> \n> (1) The user wants to keep the remotes//* namespace clean (iow,\n> the user does not care to keep old commits that were deemed bad by\n> the remote side) by removing stale tracking refs. But in this case,\n> it is very unlikely that the user would use \"git branch -d -r\" to\n> remove stale ones one-by-one after seeing '[Deleted]' label in the\n> output from \"git branch -r\". Rather he would run \"git remote prune\n> origin\" to blindly remove them all.\n> \n> (2) The user does want to be careful not to lose commits that now only\n> exists in his repository. Perhaps he saw something worthwhile to\n> base his topic later on. But these stale remote tracking refs are\n> not removed until the user runs \"git remote prune origin\". As long\n> as we give him a way to check what will be pruned before running \"git\n> remote prune\", there is not much point in showing that information in\n> output of \"git branch -r\". There is no need to keep extra info by\n> creating a new file in .git by \"fetch\". Nor showing that to the user\n> when he does \"fetch\" either, for that matter.\n> \n> A better approach to please the first class of audience may be to\n> introduce an option that tells fetch to cull tracking refs that are stale.\n\n'git remote update' already has the --prune option, so it would be only\nlogical if 'git fetch' has it too... Perhaps, it would be useful to add\na configuration option to automatically prune remote branches on fetch.\n\n> Such an option won't be very useful for the second class of audience,\n> though. For them we would need something else, and it would likely be an\n> enhancement to \"git remote\".\n\n'git remote prune' has --dry-run:\n\n$ git remote prune --dry-run origin\nPruning origin\nURL: git://git.kernel.org/pub/scm/git/git.git\n * [would prune] origin/offcuts\n * [would prune] origin/old-next\n\n(Hmm... I did not know I had them in my git repo....)\n\nSo, it is possible to do now, but personally, I would prefer if 'git\nfetch' would tell what references are removed. It may appear a bit too\nchatty if someone has a lot of deleted references in a remote repo, but\nI really do not see any good reason to keep stale branches. If you think\nthat some reference is useful and you want to preserve it then you can\ncreate a local branch, but in 99.9% cases people want just to remove a\nstale branch.\n\nActually, accumulation of stale branches is only half of the problem.\nIn some cases, the stale branch can mislead people. For instance, some\nfeature has been implemented and was merged to 'pu'. After that, this\nfeature was re-worked and later merged to the 'master' branch, after\nthat the feature branch was removed. Yet, some users may have the stale\nbranch pointing on the original version and may think that it is still\nnot merged and buggy...\n\nBTW, the current behavior of 'git fetch' does not really protect you from\nlosing commits. It protects commits only in the case when the branch is\ndeleted, but not when it is force-updated, which feels inconsistent to\nme. Personally, I would prefer if 'git fetch' removed branches, but when\nit removes or force-updates some branch, it adds a record to the reflog.\n\n\nDmitry\n"},{"id":"126918","messageId":"7v3a4sagau.fsf@alter.siamese.dyndns.org","threadId":"21481","inReplyTo":"43d8ce650911050005l6d120cb0h374f3c04b3948b25@mail.gmail.com","subject":"Re: Automatically remote prune","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-05T20:05:13Z","receivedAt":"2009-11-05T20:05:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Tapsell writes:\n\n> I omitted it just because, imho, it's not what I 'care about'. I'm\n> not trying to help advanced users (Users that _want_ to keep\n> remotes/origin/* clean and users that _want_ to be careful to not lose\n> commits are both advanced users, imho). I'm just interested in\n> reducing confusion for non-advanced users.\n\nI _think_ you are saying that your non-advanced users expect \"branch -r\"\noutput to be in sync (to the extent possible without going over the\nnetwork every time it is run) with the remote side. It is the same thing\nas keeping remotes/origin/* free of stale remote branches, i.e. they are\nin the first camp. There is nothing advanced about either of the camps.\nThe former wants the view to be in sync, the latter wants a way to avoid\ninformation loss.\n\nIt is understandable to expect \"branch -r\" output to be in sync with the\nother end, especially if one has CVS/SVN mentality but even if one\ndoesn't, I would say it is a reasonable thing to expect.\n\nI am open to an optional feature to \"git fetch' to prune them, but I would\nnot make it the default from day one. When introducing a change that\ncauses information loss, our migration strategy has always been \"Give an\noption first, release and wait for two releases or so, and then start\ndiscussing to change the default behaviour.\"\n\nThe necessary change to \"git fetch\" shouldn't be too hard to code, as we\nare already doing this in mirror mode.\n"},{"id":"126929","messageId":"76718490911051509r65af2dd2k2574e2e521fed6f2@mail.gmail.com","threadId":"21481","inReplyTo":"7v3a4sagau.fsf@alter.siamese.dyndns.org","subject":"Re: Automatically remote prune","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-11-05T23:09:03Z","receivedAt":"2009-11-05T23:09:03Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Nov 5, 2009 at 3:05 PM, Junio C Hamano wrote:\n> The necessary change to \"git fetch\" shouldn't be too hard to code, as we\n> are already doing this in mirror mode.\n\nActually, mirror mode applies to push only. Unless I'm missing\nsomething obvious.\n\nThus, adding prune to builtin-fetch duplicates the logic from\nbuiltin-remote, unless I do some refactoring. Hmph, I was hoping for a\n15 minute patch. :-(\n\nj.\n"},{"id":"126933","messageId":"20091106001619.GE17748@machine.or.cz","threadId":"21481","inReplyTo":"43d8ce650911050005l6d120cb0h374f3c04b3948b25@mail.gmail.com","subject":"Re: Automatically remote prune","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2009-11-06T00:16:19Z","receivedAt":"2009-11-06T00:16:19Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Nov 05, 2009 at 05:05:50PM +0900, John Tapsell wrote:\n> 2009/11/5 Junio C Hamano :\n> > John Tapsell writes:\n> > \"what the benefits are to give this information _in the 'branch' output_\"\n> > was what I meant.  From the part you omitted from my message:\n> \n> I omitted it just because, imho, it's not what I 'care about'. I'm\n> not trying to help advanced users (Users that _want_ to keep\n> remotes/origin/* clean and users that _want_ to be careful to not lose\n> commits are both advanced users, imho). I'm just interested in\n> reducing confusion for non-advanced users. So either not-showing\n> removed remote branches by default, or showing them but marking them\n> as deleted.\n\nMaybe, if your users want to know \"what branches does the remote repo\nhave\" instead of \"what branches does my 'image' of the remote repo has\",\njust teach them to run\n\n\tgit remote show origin\n\ninstead of\n\n\tgit branch -r origin\n\nas mentioned earlier by Junio?\n\nOf course, users would still need to realize the actual meaning of the\ncommands and the fact that Git _does_ keep a distinctive 'image of\nremote repository', so this may not be the most intuitive solution.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nA lot of people have my books on their bookshelves.\nThat's the problem, they need to read them. -- Don Knuth\n"},{"id":"126934","messageId":"20091106001751.GF17748@machine.or.cz","threadId":"21481","inReplyTo":"76718490911051509r65af2dd2k2574e2e521fed6f2@mail.gmail.com","subject":"Re: Automatically remote prune","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2009-11-06T00:17:52Z","receivedAt":"2009-11-06T00:17:52Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Nov 05, 2009 at 06:09:03PM -0500, Jay Soffian wrote:\n> On Thu, Nov 5, 2009 at 3:05 PM, Junio C Hamano wrote:\n> > The necessary change to \"git fetch\" shouldn't be too hard to code, as we\n> > are already doing this in mirror mode.\n> \n> Actually, mirror mode applies to push only. Unless I'm missing\n> something obvious.\n\nPerhaps you are, mirror mode applies to fetch as well; that's how e.g.\nrepo.or.cz mirror mode is done currently.\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"126940","messageId":"76718490911051638w7cd5306bx65ed8d9ac525d2c3@mail.gmail.com","threadId":"21481","inReplyTo":"20091106001751.GF17748@machine.or.cz","subject":"Re: Automatically remote prune","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-11-06T00:38:39Z","receivedAt":"2009-11-06T00:38:39Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Nov 5, 2009 at 7:17 PM, Petr Baudis wrote:\n> On Thu, Nov 05, 2009 at 06:09:03PM -0500, Jay Soffian wrote:\n>> Actually, mirror mode applies to push only. Unless I'm missing\n>> something obvious.\n>\n> Perhaps you are, mirror mode applies to fetch as well; that's how e.g.\n> repo.or.cz mirror mode is done currently.\n\nCan you please be more specific? There is no mention of mirror in\nbuiltin-fetch.c, only builtin-push.c. Further, the docs for\n\"remote..mirror\" indicate it's a push option only.\n\nSo please explain what you mean by \"that's how repo.or.cz mirror mode is done\".\n\nCluelessly yours,\n\nj.\n"},{"id":"126975","messageId":"20091106103100.GG17748@machine.or.cz","threadId":"21481","inReplyTo":"76718490911051638w7cd5306bx65ed8d9ac525d2c3@mail.gmail.com","subject":"Re: Automatically remote prune","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2009-11-06T10:31:00Z","receivedAt":"2009-11-06T10:31:00Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Nov 05, 2009 at 07:38:39PM -0500, Jay Soffian wrote:\n> On Thu, Nov 5, 2009 at 7:17 PM, Petr Baudis wrote:\n> > On Thu, Nov 05, 2009 at 06:09:03PM -0500, Jay Soffian wrote:\n> >> Actually, mirror mode applies to push only. Unless I'm missing\n> >> something obvious.\n> >\n> > Perhaps you are, mirror mode applies to fetch as well; that's how e.g.\n> > repo.or.cz mirror mode is done currently.\n> \n> Can you please be more specific? There is no mention of mirror in\n> builtin-fetch.c, only builtin-push.c. Further, the docs for\n> \"remote..mirror\" indicate it's a push option only.\n> \n> So please explain what you mean by \"that's how repo.or.cz mirror mode is done\".\n\nOk, I got a bit confused there. :-) For fetches, it just sets up the\nrefspec to point to main namespace instead of refs/remote/, of course it\ndoesn't use the remote.*.mirror config. I'm not sure what Junio meant by\nthe change being easy, seeing that push uses a technical trick in\nsend-pack that doesn't seem to be straightforwardly applicable to\nfetch... but I don't know this part of code too well.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nA lot of people have my books on their bookshelves.\nThat's the problem, they need to read them. -- Don Knuth\n"},{"id":"127090","messageId":"7vocncdecd.fsf@alter.siamese.dyndns.org","threadId":"21481","inReplyTo":"20091106103100.GG17748@machine.or.cz","subject":"Re: Automatically remote prune","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-08T19:08:18Z","receivedAt":"2009-11-08T19:08:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> On Thu, Nov 05, 2009 at 07:38:39PM -0500, Jay Soffian wrote:\n>> On Thu, Nov 5, 2009 at 7:17 PM, Petr Baudis wrote:\n>> > On Thu, Nov 05, 2009 at 06:09:03PM -0500, Jay Soffian wrote:\n>> >> Actually, mirror mode applies to push only. Unless I'm missing\n>> >> something obvious.\n>> >\n>> > Perhaps you are, mirror mode applies to fetch as well...\n\nSorry, my thinko. We do not do mirrors in fetch.\n"}]}