From: Jeff King <peff@peff.net>
Date: Mon, 07 Nov 2011 21:01:34 GMT
Subject: Re: [RFC/PATCH] remote: add new sync command
Message-ID: <20111107210134.GA7380@sigill.intra.peff.net>
In-Reply-To: <CAMP44s0M-qnZeHCUadSJJCYO=t881sUOi11G3fCG2vaAakPyBQ@mail.gmail.com>

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

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

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

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.

  2. git push <remote> refs/heads/*

     Turn off pruning, but use an explicit refspec, not just "matching",
     which will push all local branches.

  3. git push --prune <remote> refs/heads/*

     Turn on both features.

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

-Peff