Junio C Hamano <gitster@xxxxxxxxx> writes: > Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > >> How would I do that? The update to the remote namespace is done by Git, >> not by the remote-helper. >> >> OK, I'm now convinced that my solution is the right one. The >> alternatives are far more complex and I still fail to see the benefits. > > Sounds like a plan, even though it smells like the "update is done > by Git" that does not have any way to opt-out may be the real design > mistake and your "solution" is a work-around to that. > > Would it be a possibility to make it tunable, perhaps by introducing > a capability on the remote-interface side that allows you to tell it > not to mess with the remote namespace? Ideally, it would be possible to ask for a non-update without a fatal error on old Git versions, but this is not possible (hence, my fix is the "portable" one, that works on Git 1.8.4). But that's probably the best we can do now. > If we were doing this from scratch, I would suspect that we would have > made the capability work the other way around (Git does not do the > update by default, but helpers c an ask Git to do so). Not updating was the default until 664059fb62 (i.e. until 1.8.4), so the default already changed once. I tend to agree with Felipe that doing the update by default makes sense. git-remote-mediawiki is kind of a special case, as the remote side uses a very different data model, hence it can make sense to export+reimport to get locally what the remote side received. But when interacting with something closer to Git (bzr, hg, ...), the mapping should be close to 1-1 and re-importing wouldn't make sense. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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