Re: Automatically remote prune

[Dmitry Potapov <dpotapov@gmail.com>]

On Wed, Nov 04, 2009 at 06:23:57PM -0800, Junio C Hamano wrote:
> 
> There are two reasons I could think of that the user might want to know
> this.
> 
>  (1) The user wants to keep the remotes/<origin>/* namespace clean (iow,
>      the user does not care to keep old commits that were deemed bad by
>      the remote side) by removing stale tracking refs.  But in this case,
>      it is very unlikely that the user would use "git branch -d -r" to
>      remove stale ones one-by-one after seeing '[Deleted]' label in the
>      output from "git branch -r".  Rather he would run "git remote prune
>      origin" to blindly remove them all.
> 
>  (2) The user does want to be careful not to lose commits that now only
>      exists in his repository.  Perhaps he saw something worthwhile to
>      base his topic later on.  But these stale remote tracking refs are
>      not removed until the user runs "git remote prune origin".  As long
>      as we give him a way to check what will be pruned before running "git
>      remote prune", there is not much point in showing that information in
>      output of "git branch -r".  There is no need to keep extra info by
>      creating a new file in .git by "fetch". Nor showing that to the user
>      when he does "fetch" either, for that matter.
> 
> A better approach to please the first class of audience may be to
> introduce an option that tells fetch to cull tracking refs that are stale.

'git remote update' already has the --prune option, so it would be only
logical if 'git fetch' has it too... Perhaps, it would be useful to add
a configuration option to automatically prune remote branches on fetch.

> Such an option won't be very useful for the second class of audience,
> though.  For them we would need something else, and it would likely be an
> enhancement to "git remote".

'git remote prune' has --dry-run:

$ git remote prune --dry-run origin
Pruning origin
URL: git://git.kernel.org/pub/scm/git/git.git
 * [would prune] origin/offcuts
 * [would prune] origin/old-next

(Hmm... I did not know I had them in my git repo....)

So, it is possible to do now, but personally, I would prefer if 'git
fetch' would tell what references are removed. It may appear a bit too
chatty if someone has a lot of deleted references in a remote repo, but
I really do not see any good reason to keep stale branches. If you think
that some reference is useful and you want to preserve it then you can
create a local branch, but in 99.9% cases people want just to remove a
stale branch.

Actually, accumulation of stale branches is only half of the problem.
In some cases, the stale branch can mislead people. For instance, some
feature has been implemented and was merged to 'pu'. After that, this
feature was re-worked and later merged to the 'master' branch, after
that the feature branch was removed. Yet, some users may have the stale
branch pointing on the original version and may think that it is still
not merged and buggy...

BTW, the current behavior of 'git fetch' does not really protect you from
losing commits. It protects commits only in the case when the branch is
deleted, but not when it is force-updated, which feels inconsistent to
me. Personally, I would prefer if 'git fetch' removed branches, but when
it removes or force-updates some branch, it adds a record to the reflog.


Dmitry