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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Nov 8, 2011, 17:31 UTC
Message-ID: <CAMP44s089xbEo4VT8rqgS=BJMUu=qsb8Hm5z8bTR2akU8-5QhA@mail.gmail.com>
In-Reply-To: <20111107210134.GA7380@sigill.intra.peff.net>

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

Show 16 quoted lines

> On Mon, Nov 07, 2011 at 10:51:10PM +0200, Felipe Contreras wrote:
>
>> > What I don't understand is why it is not:
>> >
>> >  git push --mirror <URL|remote>
>>
>> Because that pushes *everything*.
>
> Ahh, I think I see. It is doing --mirror, but only on a reduced refspec?
>
> In that case, is there a reason that:
>
>  git push --prune <URL|remote> refs/heads/*
>
> would not do what you want (note that "--prune" does not exist, but I
> think it should).

I guess that should work.

Show 15 quoted lines

>> > That's what I don't understand from your proposal. Your command is just
>> > pushing something to the remote, right? Why isn't "push" the command,
>> > and your sync options become options to push?
>>
>> How exactly? --sync-prune, --sync-new, --sync-all? But actually, I was
>> thinking on adding an option to sync the other way around; to get all
>> the remote branches and have them locally.
>
> If I understand correctly, you have three modes:
>
>  1. update remote refs with local values, prune anything remote that we
>     don't have locally (--sync-prune)
>
>  2. update remote refs with local values, including pushing anything
>     new that we don't have locally (--sync-new)

Anything new that we don't have *remotely*.

>  3. push new and prune (i.e., 1 and 2 together)

Yeap.

Show 6 quoted lines

> If we had "git push --prune" as above, those would be:
>
>  1. git push --prune <remote> :
>
>     I.e., use the "matching" refspec to not push new things, but turn
>     on pruning.

I guess so, but ":" seems a bit obscure.

>  2. git push <remote> refs/heads/*
>
>     Turn off pruning, but use an explicit refspec, not just "matching",
>     which will push all local branches.

Isn't refs/heads/* the same as --all? BTW. I think --all is confusing, should be --branches, or something.

>  3. git push --prune <remote> refs/heads/*
>
>     Turn on both features.

Maybe 'git push' options should be reorganized (for 1.8.0):

--all -> --branches --tags (same) --mirror -> --all --update = : --prune (new)

In the meantime, we could add --update and --prune, which would not conflict.

Show 10 quoted lines

>> Well, I usually have quite a lot of branches in my local repositories,
>> like a dozen of so. And I like to back them up in some remote
>> repository, however, not all the branches all the time. git push
>> --mirror not only pushes branches, but also tags (and I don't want
>> that), and even other refs. Does that clarifies things?
>
> That makes sense. But I think it fits in with git's current UI to do
> this via a combination of push options and refspecs. Even if we want to
> wrap it in some "git remote" command for convenience, I think what
> you're asking should be implemented as part of "git push".

Perhaps. I will give that a try, let's see how the code ends up.

But then, maybe similar options should be added to 'git fetch' to do the same in the opposite direction, and that's where things get a bit ugly:

--all -> rename to --all-remotes? --prune -> rename to --prune-tracking? --prune-local (new; prune local branches that don't exist on the remote) --all (new; similar to 'git push --all' [--mirror]) --tags (same) --update (new; similar to 'git push --update') --branches (new; similar to 'git push --branches')

Somehow I fell there should be a 'sync' command somewhere to differentiate these options from normal 'git fetch/push' commands.

Cheers.

-- 
Felipe Contreras