Re: [PATCH v6 06/10] fast-export: add new --refspec option

[Junio C Hamano <gitster@pobox.com>]

Richard Hansen <rhansen@bbn.com> writes:

>>> I thought that the discussion agreed this option should not be
>>> called --refspec but something like --refmap?
>> 
>> I don't know what you agreed to,
>
> http://article.gmane.org/gmane.comp.version-control.git/237473

Yup, that was what I had in mind.

>> but I didn't agree to anything.
>
> Based on your silence I too thought that you had agreed.

Careful.  Silence does not mean agreement, at least around here.  It
may be just the person was busy and hasn't got around to it, was not
paying attention and missed the discussion, or was not as interested
in the topic as his/her other activities.

That, especially the last possibility among the three example
reasons above, was why I said "the discussion agreed", not "you
agreed".

>> What you pass to this option is a refspec, so it makes sense to name
>> the option --refspec.
>
> As discussed in that thread, it's not really the same thing as a refspec
> used in push or fetch.  In those commands, the refspec specifies two
> separable things:  what to transfer, and how to translate refs names
> between the remote and local repositories.  IIUC, the fast-export
> --refspec argument only specifies how to translate ref names, not what
> gets transferred.
>
> If my understanding is correct, then I agree with Junio and Peff that
> --refmap is a better name.

I know from one of the tests that the option Felipe added is
implemented in such a way that allows:

    git fast-export --option refs/heads/master:refs/heads/next master

to rename the destination, but I didn't check, when I wrote the
message to envision how a similar mechanism could be used to enhance
push/fetch in the future, if it can be actually used as a mapping

    git fast-export --option refs/heads/*:refs/remotes/mine/* master

Being able to do so was the only reason why I agree with the patch
in question (not my toy patch, but [6/10] that started this thread)
that it is a good idea in the longer term, as the other approach I
suggested to teach revision command line parser to optionally take
refspecs as if they specify LHS of the colon as object name with
rev_cmdline annotations would not work well for such a purpose.

Thanks.