Re: Feature request: fetch --prune by default

[Konstantin Khomoutov <flatworm@users.sourceforge.net>]

On Thu, 19 Jul 2012 18:21:21 +0200
Alexey Muranov <alexey.muranov@gmail.com> wrote:

[...]
> 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.
This is wery well explained in the Pro Git book, for instance.
And in numerous blog posts etc.

> 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.
This would present another namespacing issue: how would you name the
branches you're interested in so that they don't clash with your own
personal local branches?  You'd have to invent a scheme which would
encode the remote's name in a branch name.  But remote branches already
do just this.  So you create a remote tracking branch when you intend
to actually *develop* something on that branch with the final intention
to push that work back.

> > 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.
It appears, the distributed nature of a DVCS did not fully sink into
your mindset yet. ;-)
Looks like you mentally treat a Git remote as a thing being used to
access a centralized "reference" server which maintains a master copy
of a repository, of which you happen to also have a local copy.
Then it's quite logically to think that if someone deleted a branch in
the master copy, everyone "downstream" should have the same
remote branch deleted to be in sync with that master copy.
But this is not the only way to organize your work.
You could fetch from someone else's repository and be interested in
their branch "foo", but think what happens when you fetch next time from
that repo and see Git happily deleting your local branch thatremote/foo
simply because someone with push access deleted that branch from the
repo.  This might *not* be what you really want or expect.