On 19 Jul 2012, at 13:55, Jeff King wrote: > 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.-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html