{"thread":{"id":"22491","subject":"Suggestions for improvement when dealing with remote branch shuffling","startedAt":"2010-02-02T17:11:03Z","lastAt":"2010-02-02T17:11:03Z","messageCount":1,"participants":["Yann Dirson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"133367","messageId":"20100202171103.GK2725@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"22491","inReplyTo":null,"subject":"Suggestions for improvement when dealing with remote branch shuffling","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2010-02-02T17:11:03Z","receivedAt":"2010-02-02T17:11:03Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"* it looks like \"git remote prune\" on any remote may be a good candidate to be\nincluded in \"git gc\" (although probably only for the candidate refs seeing their\nlast reflog entry removed)\n\n* when a remote had a \"foo/bar\" ref in the past, still available locally as\n\"remotes/origin/foo/bar\" because the user did not think about running \"remote\nprune origin\", and a new remote branch named \"foo\" appears, fetch refuses to\nupdate the local \"remotes/origin/foo\" ref, but does not give the reason to the\nuser. OTOH, another user reported fetch suggesting running \"remote prune origin\"\n- but he may have had a slightly different history of fetch runs (seen in\n1.6.5.1 msys). Probably this message should also be issued in the 1st case.\n"}]}