git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [RFC/PATCH] remote: add new sync command
Date: Fri, 11 Nov 2011 14:30:48 +0200	[thread overview]
Message-ID: <CAMP44s2RjcFtdO2jft0Hg9RtqK-DRK47gX8By-dBFSBcSA+yFA@mail.gmail.com> (raw)
In-Reply-To: <20111108181442.GA17317@sigill.intra.peff.net>

On Tue, Nov 8, 2011 at 8:14 PM, Jeff King <peff@peff.net> 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

  reply	other threads:[~2011-11-11 12:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-07 16:07 [RFC/PATCH] remote: add new sync command Felipe Contreras
2011-11-07 17:22 ` Jeff King
2011-11-07 18:35   ` Felipe Contreras
2011-11-07 18:39     ` Jeff King
2011-11-07 20:51       ` Felipe Contreras
2011-11-07 21:01         ` Jeff King
2011-11-07 21:25           ` Junio C Hamano
2011-11-07 21:31             ` Jeff King
2011-11-08 16:43             ` Felipe Contreras
2011-11-08 17:49               ` Junio C Hamano
2011-11-08 17:59                 ` Felipe Contreras
2011-11-09  3:36                   ` Junio C Hamano
2011-11-11 10:35                     ` Jakub Narebski
2011-11-11 16:38                       ` Junio C Hamano
2011-11-11 22:00                         ` Jakub Narebski
2011-11-08 17:31           ` Felipe Contreras
2011-11-08 18:14             ` Jeff King
2011-11-11 12:30               ` Felipe Contreras [this message]
2011-11-11 18:13                 ` Jeff King
2011-11-12 22:07                   ` Felipe Contreras
2011-11-14 12:25                     ` Jeff King
2011-11-14 13:57                       ` Felipe Contreras
2011-11-21 21:44                         ` Jeff King
2011-11-21 23:47                           ` Felipe Contreras
2011-11-30  7:01                             ` Jeff King
2011-11-30 11:47                               ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMP44s2RjcFtdO2jft0Hg9RtqK-DRK47gX8By-dBFSBcSA+yFA@mail.gmail.com \
    --to=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).