Re: Automatically remote prune

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 5, 2009, 20:05 UTC
Message-ID: <7v3a4sagau.fsf@alter.siamese.dyndns.org>
In-Reply-To: <43d8ce650911050005l6d120cb0h374f3c04b3948b25@mail.gmail.com>

John Tapsell <johnflux@gmail.com> writes:

Show 5 quoted lines

> I omitted it just because, imho, it's not what I 'care about'.  I'm
> not trying to help advanced users (Users that _want_ to keep
> remotes/origin/* clean and users that _want_ to be careful to not lose
> commits are both advanced users, imho).  I'm just interested in
> reducing confusion for non-advanced users.

I _think_ you are saying that your non-advanced users expect "branch -r" output to be in sync (to the extent possible without going over the network every time it is run) with the remote side. It is the same thing as keeping remotes/origin/* free of stale remote branches, i.e. they are in the first camp. There is nothing advanced about either of the camps. The former wants the view to be in sync, the latter wants a way to avoid information loss.

It is understandable to expect "branch -r" output to be in sync with the other end, especially if one has CVS/SVN mentality but even if one doesn't, I would say it is a reasonable thing to expect.

I am open to an optional feature to "git fetch' to prune them, but I would not make it the default from day one. When introducing a change that causes information loss, our migration strategy has always been "Give an option first, release and wait for two releases or so, and then start discussing to change the default behaviour."

The necessary change to "git fetch" shouldn't be too hard to code, as we are already doing this in mirror mode.