Re: [RFC/PATCH] remote: add new sync command

[Jeff King <peff@peff.net>]

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.

> > 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?).

> > 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:

  git fetch --prune <remote> refs/*:refs/*

_supposed_ to do, if not prune your local namespace?

I don't buy the "it's too risky" argument. You have configured a remote
that will fetch and overwrite your local branches already, if you ever
run "git fetch foo". But somehow running "git fetch --prune foo" is too
risky, because you might forget that it will delete all of your
branches?

> > 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.

> > 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.

-Peff