On Wed, Nov 30, 2011 at 9:01 AM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Nov 22, 2011 at 01:47:36AM +0200, Felipe Contreras wrote: > >> > I didn't mean "you didn't define a mirror in your config". I meant "your >> > question is not well-defined, because you haven't defined the term >> > 'mirror'". IOW, I can't answer your question without knowing exactly >> > what you meant. >> >> I wasn't the one that brought the mirror up, you did: > > Yes, because that is the most related concept in current git. But I > thought you were asking from the perspective of a clueless user, and I > don't know what that clueless user meant by "mirror". I don't think common users know, or should care about, what a "mirror" is. > Anyway, I don't think it's important. Me neither. > I read over your whole message, and I feel like our discussion isn't > really moving towards an actual goal. Junio and I both mentioned that in > the long-term, features like this should be part of "push", not > "remote". Do you want to try revising your patch in that direction? Yes, I can try that for 'git push', but my worry is about 'git fetch'. To me it's really clear that what I am trying to achieve is more complicated than a simple push/fetch. You still haven't replied to my solution to synchronize the local branches, which to first do a 'git fetch' so we have the remote branches tracked locally, and go through each one of them and do something to the local ones. This solution works, is simple, and allows all kinds of options, but IMO it's not part of 'git fetch'. > That will give us something concrete to talk about (and hopefully > apply). Yes, but that's basically 'git push --prune', which I think is the only thing we have agreed. But what about the rest? I feel you are trying to ignore the fact that 'refs/heads/*' is not user-friendly, neither is BRANCHES, or :, and 'git fetch' would be even more cumbersome. The user-friendliness of git is one of the biggest complains people have, and while it makes sense to keep certain operations under push/fetch, there's only so much pureness we can have before things become too complicated for the users. The fact of the matter is that these particular remote synchronization operations are much easier to picture mentally in a group like 'git remote sync'. That not only works for all the cases, including 'git fetch', but it's non-intrusive, and most importantly: user-friendly. Cheers. -- Felipe Contreras -- 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