From: Jay Soffian <jaysoffian@gmail.com>
Date: Thu, 26 Aug 2010 02:26:31 GMT
Subject: Re: [BUG] git fetch --prune --tags origin deletes all remote branches origin/*
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:
> 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:

> 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.