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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Nov 21, 2011, 23:47 UTC
Message-ID: <CAMP44s3StLjb9KgBkRrG4nPqJD_ZjeSyFUwuP4A3b+mJKBgHWQ@mail.gmail.com>
In-Reply-To: <20111121214450.GA20338@sigill.intra.peff.net>

On Mon, Nov 21, 2011 at 11:44 PM, Jeff King <peff@peff.net> wrote:

Show 18 quoted lines

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

Show 15 quoted lines

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

Show 13 quoted lines

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

Show 15 quoted lines

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

Show 22 quoted lines

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