Re: [PATCH 3/3 v2] Make "git-remote rm" delete refs acccording to fetch specs

["Shawn O. Pearce" <spearce@spearce.org>]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> >  This is a longer, but better version of this patch.  Instead of
> >  blindly deleting the refs we remove them only if this is the last
> >  remote that would write to the local tracking ref.
> 
> If this is a better version than the previous one, then probably "git
> remote prune" patch to unconditionally remove ones that do not exist in
> one of the remotes that fetch into the tracking namespace also needs to be
> rethought, doesn't it?

Nope.  I've thought about this already.  ;-)
 
> Admittedly, next fetch from the other remote may or may not resurrect them
> and either way it is not a big deal.

Correct.

> I think this is exactly the same issue as this improvement in [3/3] deals
> with.  If "git remote rm" of one remote removed the shared tracked refs,
> next fetch from the other remote would resurrect them if the other remote
> still exists.  It may probably feel better to be extra careful like this
> improved patch, but I doubt it would matter in practice.  After all,
> people who creates such a configuration would know what they are doing.

I don't think it matters in practice.

If the user has configured two different remotes with different URLs
fetching to the same set of tracking branches, well, they get what
they get when their prune and fetch start fighting over a tracking
branch existing or disappearing.

Today I found these misfeatures in git-remote because I sort of do
what I showed in my second patch.  I have two remotes which fetch to
the same tracking branches, as they fetch from the same repository,
just over two different protocols.  There never should be a time
where I can see a difference between them, unless its just a race
condition where someone else created or deleted a branch between
my two sequential git-fetch/git-remote calls.

I think the behavior in 2/2 and 3/3v2 is the best we can do, short of
contacting all other remotes which go to the same tracking branch.
But that may not be possible.  One reason for using two different
remote configurations to the same tracking branches is to make
the URL differ.  Think fetching against repo.or.cz using git://
and also http://, where http:// is necessary when you are stuck
behind a @#U*!@(#*!@#*!@(@!! proxy server.  We cannot contact both
remotes to verify the branch really is safe to prune.

-- 
Shawn.