On Tue, Nov 8, 2011 at 8:14 PM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Nov 08, 2011 at 07:31:09PM +0200, Felipe Contreras wrote: > >> > 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. > > Yeah, it is. It's also the default, so you could just do: > > git push --prune <remote> That would work only if not configured otherwise; remote.<foo>.push, push.default > Although some people have argued for changing the default in future > versions. I don't know what the status of that is. IMO the default doesn't matter, it should be easy for everyone. >> > 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. > > Doesn't --all mean all refs, including tags and branches? Nope, only branches, try it. I also found it strange. And what is more, you can't use --all and --tags at the same time. Totally strange. Also, --all doesn't push other refs (say refs/foobar/test) I think this area has been neglected. > I thought that was the thing you were avoiding. --all + --tags is not the same as --mirror (refs/foobar/* is pushed only by --mirror). And yes, in this particular use-case that's what I am trying to avoid, but in other use-cases (like creating a new repo and pushing *everything*), a *true* --all would be nice. > We could add syntactic sugar to make > --branches mean "refs/heads/*". But I do worry that pseudo-options like > that just end up creating more confusion (I seem to recall there being a > lot of confusion about "--tags", which is more or less the same thing). But it's not, that could explain part of the confusion. I think these would be totally intuitive. --branches --tags --other --all --update --prune But what about 'git fetch'? You didn't comment anything. I think we should try to be consistent in these imaginary future options, maybe to devise a transition, or at least to identify good names for the new options. 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