Re: Automatically remote prune

[Junio C Hamano <gitster@pobox.com>]

John Tapsell <johnflux@gmail.com> writes:

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