On Mon, Nov 7, 2011 at 11:01 PM, Jeff King <peff@xxxxxxxx> wrote: > 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. >> > 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. > 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. >> 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 -- 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