Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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. -- 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
