{"thread":{"id":"44897","subject":"\"git fetch -p\" incorrectly deletes branches","startedAt":"2017-01-17T05:08:37Z","lastAt":"2017-01-26T21:18:41Z","messageCount":2,"participants":["Reimar Döffinger","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"309510","messageId":"20170117060428.nanqz5lr4hi6dum6@reimardoeffinger.de","threadId":"44897","inReplyTo":null,"subject":"\"git fetch -p\" incorrectly deletes branches","fromName":"Reimar Döffinger","fromEmail":"reimar.doeffinger@gmx.de","sentAt":"2017-01-17T06:04:28Z","receivedAt":"2017-01-17T05:08:37Z","isPatch":false,"sender":{"key":"reimar.doeffinger@gmx.de","avatar":null},"body":"Hello!\nThe command:\ngit fetch -p -v origin master:refs/heads/test\n\nDeletes refs/heads/test every second time when run repeatedly:\n\n$ git fetch -p -v origin master:refs/heads/test\nFrom https://github.com/git/git\n * [new branch]          master     -> test\n = [up to date]          master     -> origin/master\n$ git fetch -p -v origin master:refs/heads/test\nFrom https://github.com/git/git\n - [deleted]             (none)     -> test\n = [up to date]          master     -> test\n = [up to date]          master     -> origin/master\n\n(the command is the result of cutting down the test case,\nso yes it is rather silly, but the issue appears in much\nless obviously silly cases and causes a lot of confusion)\nThis is specific to the case of specifying the origin branch\nwithout \"full path\" AND the right side with.\nWild-guess on cause: \"master\" is auto-expanded into both\n\"refs/tags/master\" and \"refs/heads/master\" and instead of\nfetching either/merging the result, both are fetched.\nCombined with a time-of-check/time-of-use style race condition\non the code that checks if a ref is \"up to date\" on top of it,\nit would result in this behaviour.\nAlso note that this behaviour appears also when fetch.prune=yes\nis set in the config (instead of -p on the command-line),\nwhich makes it much less obvious and there is no option to turn\nof prune just for that command to work-around this.\nI hope someone has the time to make sure nobody else has to\ndebug this ever again ;-)\n\nRegards,\nReimar Döffinger\n"},{"id":"310361","messageId":"20170126211834.eplmjcohv3d4zsym@sigill.intra.peff.net","threadId":"44897","inReplyTo":"20170117060428.nanqz5lr4hi6dum6@reimardoeffinger.de","subject":"Re: \"git fetch -p\" incorrectly deletes branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-01-26T21:18:34Z","receivedAt":"2017-01-26T21:18:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 17, 2017 at 07:04:28AM +0100, Reimar Döffinger wrote:\n\n> Deletes refs/heads/test every second time when run repeatedly:\n> \n> $ git fetch -p -v origin master:refs/heads/test\n> From https://github.com/git/git\n>  * [new branch]          master     -> test\n>  = [up to date]          master     -> origin/master\n> $ git fetch -p -v origin master:refs/heads/test\n> From https://github.com/git/git\n>  - [deleted]             (none)     -> test\n>  = [up to date]          master     -> test\n>  = [up to date]          master     -> origin/master\n\nHmm. It seems like the problem is that \"-p\" is saying \"the other side\ndoes not have refs/heads/test; we must prune it\". But I think it is\nprobably nonsense to apply pruning to a non-wildcard refspec.\n\n\n> Also note that this behaviour appears also when fetch.prune=yes\n> is set in the config (instead of -p on the command-line),\n> which makes it much less obvious and there is no option to turn\n> of prune just for that command to work-around this.\n\nThere is a separate issue of whether it is sane to apply fetch.prune to\na refspec given on the command line; I can imagine it as surprising, to\nsay the least.\n\nI think \"--no-prune\" would disable it, though.\n\n-Peff\n"}]}