On Sun, 2008-06-01 at 02:30 -0400, Shawn O. Pearce wrote: > 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. This all seems sort of fragile to me. Like maybe there is a different name-space concept itching to get out here. Like a [refspec "foo"] node in the config file or something that clearly states the expected namespace for an remote. > 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. Didn't we settle on an alternate URL mechanism that covered this case already? Or was that a different case/ CRS, jdl -- 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
