Re: Feature request: fetch --prune by default

From: Alexey Muranov <alexey.muranov@gmail.com>
Date: Jul 19, 2012, 16:21 UTC
Message-ID: <88300470-AB41-4317-8B97-81DC18FD5899@gmail.com>
In-Reply-To: <20120719115558.GC29774@sigill.intra.peff.net>

On 19 Jul 2012, at 13:55, Jeff King wrote:

Show 19 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".

I do not still understand very well some aspects of Git, like the exact purpose of "remote tracking branches" (are they for pull or for push?), so i may be wrong. However, i thought that a user was not expected to follow the moves of a remote branch of which the user is not an owner: if the user needs to follow the brach and not lose its commits, he/she should create a remote tracking branch.

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

I prefer to think of a remote branch and its local copy as the same thing, which are physically different only because of current real world/hardware/software limitations, which make it necessary to keep a local cache of remote data.  With this approach, reflogs should be deleted with the branch, and there will be no namespace conflicts.

Alexey.