On Wed, Aug 25, 2010 at 7:52 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Kevin Ballard <kevin@xxxxxx> writes: > >> Running the simple command `git fetch --prune --tags origin` will delete >> every single remote branch refs/remotes/origin/*, with the sole >> exception of refs/remotes/origin/HEAD. This is wildly unexpected >> behavior. This was reproduced on the tip of the next branch, with >> version git version 1.7.2.2.440.g49ea7. > > I suspect "--prune --tags" behaved like that from the very beginning of > the appearance of "--prune", Indeed. The logic was refactored from "git remote prune" which doesn't support --tags. The quick fix would be to make --prune --tags and unsupported combination. However: > and also it is not limited to --tags. With > this: > > [remote "origin"] > url = $over_there > fetch = refs/heads/master:refs/heads/origin > fetch = refs/heads/next:refs/heads/next > > "git fetch --prune origin master" would probably remove your local next. I would think "remote prune" suffered the same fate in that situation. > get_stale_heads() seems to assume that it has the list of all existing > refs from the remote side available to make its decision. Unless the > fetch is done using a list of refs configured with remote.<name>.fetch, I > do not think that assumption holds. > > f2ef607 (remote: refactor some logic into get_stale_heads(), 2009-11-10) > f360d84 (builtin-fetch: add --prune option, 2009-11-10) I'm not sure what the best fix here is. It would seem prune should obey the user's fetch spec. j. -- 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