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).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html