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

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