Re: Automatically remote prune

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

John Tapsell <johnflux@gmail.com> writes:

> 2009/11/5 Junio C Hamano <gitster@pobox.com>:
>> John Tapsell <johnflux@gmail.com> writes:
>
>> You could store necessary information somewhere else when you contacted
>> the remote the last time, but we need to consider what the benefits are to
>> give this information in the first place.
>
> We already get all this information on a "git fetch", no?

"what the benefits are to give this information _in the 'branch' output_"
was what I meant.  From the part you omitted from my message:

    The [Deleted] mark in your suggestion tells the user:

        This is already removed in the remote, and this tracking copy is the
        only way for you to view it ever again.  Do not run 'remote prune
        origin' blindly otherwise you will lose it.

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.
Then "branch -r" output will not show stale refs and there is no place
(nor need) to show [Deleted] labels.

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".  It would ask the other side what refs are no
longer there, and then check our local refspace to see if there are local
topics based on them (which would mean the user is already in a trouble)
and which ones are not forked locally at all (which may mean "it wasn't
interesting to the user, and we can safely remove it" or "the user was
interested in it, but hasn't got around to forking from it yet, being busy
working on something else").  I am unsure what should be done in the
latter case (i.e. lost remote refs haven't been touched locally) but am
just thinking aloud.