Re: [BUG] git fetch --prune --tags origin deletes all remote branches origin/*
- From
Jay Soffian <jaysoffian@gmail.com>
- Date
- Aug 26, 2010, 02:26 UTC
- Message-ID
- <AANLkTi=CEBZOK11uyb1SCF8fTc0CyWaEUxMFAv6-=MyB@mail.gmail.com>
- In-Reply-To
- <7vsk22ntcl.fsf@alter.siamese.dyndns.org>
On Wed, Aug 25, 2010 at 7:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> Kevin Ballard <kevin@sb.org> 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:
Show 9 quoted lines
> 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.
Show 7 quoted lines
> 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.