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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 12, 2013, 17:08 UTC
Message-ID: <xmqqtxfhim4t.fsf@gitster.dls.corp.google.com>
In-Reply-To: <5281DB46.2010004@bbn.com>

Richard Hansen <rhansen@bbn.com> writes:

Show 6 quoted lines

>>> 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".

Show 12 quoted lines

>> 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.