On Mon, Nov 21, 2011 at 11:44 PM, Jeff King <peff@xxxxxxxx> wrote: > On Mon, Nov 14, 2011 at 03:57:07PM +0200, Felipe Contreras wrote: > >> >> I'm not going to investigate the subtleties of these different setups, >> >> I'm going to put my common user hat and ask; how do I fetch as a >> >> mirror? >> > >> > The problem with that question is that you haven't defined mirror. Does >> > that mean you just want pruning, or does it mean that you want your >> > local ref namespace to match that of the remote? >> >> Exactly, no mirror has been defined, because I don't want a mirror. A >> mirror is supposed to have all the refs in sync all the time; that's >> not what I want. > > 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: > I think --prune wouldn't need renaming. If you fetch into tracking > branches, then pruning would prune tracking branches. If you fetch as a > mirror (refs/*:refs/*), then you would prune everything. So you should know what you meant :) >> > BTW, right now there is "git remote add --mirror ...", which sets up the >> > fetch refspec for you (in this case, mirror is "make your refs look like >> > the remote's"). Perhaps rather than adding syntactic sugar to fetch, it >> > would be best to channel users into configuring a remote that selects >> > from one of a few common setups (including different types of mirrors). >> >> But that assumes that they would want the same refspec operation *all >> the time* which is not the case (at least for me). Sometimes I want to >> update only existing branches, sometimes I want to fetch new branches >> too, sometimes I want to prune local branches, sometimes not. > > OK, then that means it must be a fetch command-line thing, not a > configured thing. Though note that even leaving prune out, I don't think > git does what you want (e.g., how are you fetching only to update > existing branches?). It should be possible to do a git fetch, so the remote tracking branches are updated, and then compare those with the local ones. This might not feel natural under 'git fetch' which is why I decided to use 'git remote sync'. >> > No, you would just do "--prune", because your refspecs are _already_ >> > indicating that you are writing into the local namespace, and anything >> > you have locally would be deleted by the prune operation. I.e., there is >> > no need for --prune-local in this scenario; --prune already does what we >> > want. >> >> That's very risky. The user might forget that this is a mirror repo, >> and delete the local branches unintentionally. Plus, it would be then >> impossible to prune remote tracking branches. > > Sorry, but I don't see how "--prune" is supposed to know what to prune > except through the refspecs that have been provided to it (either in > configuration or on the command line). So what is: That's why I suggested --prune-local. > git fetch --prune <remote> refs/*:refs/* > > _supposed_ to do, if not prune your local namespace? I thought 'git fetch --prune <remote_mirror>' would not prune the local branches, but now I see that it does (currently), so nevermind. >> > As a user, how do I resolve the situation? I might say topic-Y is >> > obsolete and get rid of it. I might rebase it onto another branch. Or I >> > might declare it to have no upstream. But all of those are branch >> > operations, not fetch operations. >> >> Yes, but that has nothing to do with the operation I want to achieve: >> git remote sync. By which I mean synchronize the local branches with >> the branches of a certain remote. > > Right. I was only trying to explain a case where you would want to prune > in the local namespace, when fetch is not configured to touch the local > namespace. Which is the only use case I could think of for something > named --prune-local. But let's forget it. My point was that it is not > related to fetch, and I was just guessing at what you might want from > --prune-local. Basically 'git fetch --prune <remote> refs/*:refs/*', when the remote is not configured as a mirror. But it would be nice to prune the branches without having to update the local ones (for whatever reason). >> > So what I was trying to say was that either your fetch refspecs tell >> > fetch to write into your local branch namespace, or not. If they do, >> > then --prune is sufficient (with no -local variant required). If not, >> > then touching your local branch namespace is outside the scope of fetch. >> >> I don't want this to be a *permanent* configuration. I see this >> similar to --force. You can achieve the same by adding a + at the >> beginning of the refspec, but this is something that should be >> activated on a per-command basis, thus the option. I think this should >> be the same. > > Then you can tweak what is pruned on a per-command basis by providing > alternate refspecs. Right now that would probably mean: > > git fetch --prune <remote> refs/*:refs/* > > or > > git fetch --prune <remote> refs/heads/*:refs/remotes/<remote>/* > > but as we discussed earlier in the thread, those can be made less scary > with syntactic sugar. Indeed, but those commands will also update the local branches. -- 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