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

> On Sun, Nov 13, 2011 at 12:07:19AM +0200, Felipe Contreras wrote:
>
>> > So in that sense, it is poorly named, and "--branches" (or "--heads")
>> > would be more accurate. At the same time, it is probably more likely
>> > what the user wants to do (you almost never want to push "refs/remotes",
>> > for example).
>>
>> But you do want to push tags, and --all --tags doesn't sound right; if
>> I'm pushing everything, why do I specify I want to push more stuff.
>> And then, why it --all --tags disallowed?
>
> I agree that "--all --tags" looks silly. I don't know why it's
> disallowed; from my reading, it should be a perfectly sensible
> operation. You might try digging in the history or the mailing list.

>> > So I am a little hesitant to suggest changing it, even
>> > with a warning and deprecation period.
>>
>> It is confusing and wrong, what more reason do you need?
>
> Because I am worried that "--all" pushing refs/remotes will also be
> confusing; it's not what most people are going to want.
>
> If your suggestion is to deprecate the name "--all" and start calling it
> "--branches" or "--heads", then that is an improvement. But making
> "refs/*:refs/*" easier to accidentally use might not be.

>> > and then it really is just a special way of spelling "refs/heads/*". But
>> > then, I also think it's good for users to understand that the options
>> > are refspecs, and what that means. It's not a hard concept, and then
>> > when they inevitably say "how can I do BRANCHES, except put the result
>> > somewhere else in the remote namespace", it's a very natural extension
>> > to learn about the right-hand side o the refspec.
>> >
>> > Of course I also think BRANCHES looks ugly, and people should just learn
>> > "refs/heads/*".
>>
>> Look, I'm all in favor of people learning stuff, but I have been
>> involved in Git since basically day 1, and up to this day I was (am?)
>> not familiar with refspecs, I don't use them regularly, and never
>> really had a need to, and that's fine. People are already complaining
>> about the learning curve of git, and what you are suggesting is that:
>>
>> Instead of doing:
>> % git push remote --branches --tags
>>
>> They should do:
>> % git push remote 'refs/heads/*' 'refs/tags/*'
>
> Sorry, I should have been more clear with what I wrote. My "of
> course..." was more of a tangential "well, this is so far from what my
> gut tells me is reasonable that I'm not sure my definition of ugly is
> even relevant here".
>
> For me personally as a user, I prefer learning how a tool actually works
> at its core (in this case, refspecs), and then applying syntactic sugar
> to simplify usage. But I also respect that not everybody feels that way.
>
>> I'm not going to investigate the subtleties of these different setups,
>> I'm going to put my common user hat and ask; how do I fetch as a
>> mirror?
>
> The problem with that question is that you haven't defined mirror. Does
> that mean you just want pruning, or does it mean that you want your
> local ref namespace to match that of the remote?

> Git should be able to do each of those cases. And I think it's fine to
> have a less cumbersome syntax to specify them. But it's also important
> that we don't over-simplify the terms so much that they get option A
> when they wanted B.
>
> BTW, right now there is "git remote add --mirror ...", which sets up the
> fetch refspec for you (in this case, mirror is "make your refs look like
> the remote's"). Perhaps rather than adding syntactic sugar to fetch, it
> would be best to channel users into configuring a remote that selects
> from one of a few common setups (including different types of mirrors).

>> > And "--prune-local" doesn't seem like a fetch operation to me. Either
>> > you are mirroring, and --prune already handles it as above. Or you are
>> > interested in getting rid of branches whose upstream has gone away. But
>> > that's not a fetch operation; that's a branch operation.
>>
>> This would make things more confusing to the user.
>>
>> Say on one side I do this push?
>> % git push test --prune 'refs/heads/*' 'refs/tags/*'
>>
>> What do I do in the other side to synchronize the repo?
>> % git fetch test --prune-local 'refs/heads/*:refs/heads/*'
>> 'refs/tags/*:refs/tags/*'
>
> No, you would just do "--prune", because your refspecs are _already_
> indicating that you are writing into the local namespace, and anything
> you have locally would be deleted by the prune operation. I.e., there is
> no need for --prune-local in this scenario; --prune already does what we
> want.

>> I would prefer this of course:
>> % git fetch test --all --prune-local
>>
>> But you are saying it should be:
>> % git fetch test 'refs/heads/*:refs/heads/*' 'refs/tags/*:refs/tags/*'
>> % git branch --prune-remote test
>>
>> That doesn't sound right to me; mixing branch operations with a specific remote?
>
> I was trying to outline a situation where "--prune" wouldn't be
> sufficient, which is:
>
>  : we make some topic branch based on another branch
>  $ git checkout -b topic-Y origin/topic-X
>
>  : later, we (or someone else) deletes topic-X upstream
>  $ git push origin :topic-X
>
>  : now we fetch using the regular default refspecs, which put
>  : everything in a separate remote. But we ask to prune, so that
>  : deleted branches will go away.
>  $ git fetch --prune origin
>
> Now origin/topic-X doesn't exist, even though it's configured as the
> upstream of topic-Y. Fetch doesn't enter into the picture, because it is
> configured to only touch items in refs/remotes/.