Re: Feature request: fetch --prune by default

From: Dan Johnson <computerdruid@gmail.com>
Date: Jul 19, 2012, 14:03 UTC
Message-ID: <CAPBPrnsFk-Ww-52W-=qkTK7Yifjowx3tpsELznO4ncmqwfP_Qg@mail.gmail.com>
In-Reply-To: <20120719115558.GC29774@sigill.intra.peff.net>

On Thu, Jul 19, 2012 at 7:55 AM, Jeff King <peff@peff.net> wrote:

Show 24 quoted lines

> On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote:
>
>> i would like
>>
>> `git fetch --prune <remote>`
>>
>> to be the default behavior of
>>
>> `git fetch <remote>`
>>
>> In fact, i think this is the only reasonable behavior.
>> Keeping copies of deleted remote branches after `fetch` is more confusing than useful.
>
> I agree it would be much less confusing. However, one downside is that
> we do not keep reflogs on deleted branches (and nor did the commits in
> remote branches necessarily make it into the HEAD reflog). That makes
> "git fetch" a potentially destructive operation (you irrevocably lose
> the notion of which remote branches pointed where before the fetch, and
> you open up new commits to immediate pruning by "gc --auto".
>
> So I think it would be a lot more palatable if we kept reflogs on
> deleted branches. That, in turn, has a few open issues, such as how to
> manage namespace conflicts (e.g., the fact that a deleted "foo" branch
> can conflict with a new "foo/bar" branch).

In the meantime, would it make sense to introduce a configuration variable to request this behavior?

If so, should it be global?

fetch.prune = always

or per-remote?

remote.<name>.prune = always

The global option seems to be more in line with what Alexey is looking for, but the per-remote one is similar to the tagopt option, which is a similar idea.

Of course, this might be just a waste of time to introduce a feature no one would use, in which case we obviously should not introduce such options.

-- 
-Dan