Felipe Contreras [off-list ref] writes:
On Thu, Oct 31, 2013 at 12:26 PM, Junio C Hamano [off-list ref] wrote:
quoted
Felipe Contreras [off-list ref] writes:
quoted
+test_expect_success 'use refspec' '
+ git fast-export --refspec refs/heads/master:refs/heads/foobar master | \
+ grep "^commit " | sort | uniq > actual &&
It feels somewhat redundant that you have to twice say that you are
pushing your "master", once with --refspec and then the branch
name. Is this the best we can do?
As this has been discussed before and no other solution came forward, yes.
We need to take that "no other solution came forward" with a grain
of salt. After all, this is your itch, and if nobody was interested
in helping you (which I think that we both understand entirely
plausible, given the recent history), it only means you didn't think
of any other solution.
I didn't think things through, but at the external UI level, I see a
possibility of a nicer way to express the above.
In our "push" refspec (and export is about pushing what we have), a
colonless refspec A is a short-hand for A:A, so the traditional
git fast-export master
can be thought of, in a new world order with a patch that lets you
do a ref mapping, a short-hand for an identical mapping:
git fast-export master:master
It follows that the syntax naturally support
git fast-export refs/heads/master:refs/heads/foobar
I would think.
That approach lets you express ref mapping without a new option
--refspec, which goes contrary to existing UI for any commands in
Git (I think nobody takes refspec as a value to a dashed-option in
the transport; both in fetch and push, they are proper operands,
i.e. command line arguments to the command), no?
On Wed, Nov 06, 2013 at 01:00:42PM -0800, Junio C Hamano wrote:
I didn't think things through, but at the external UI level, I see a
possibility of a nicer way to express the above.
In our "push" refspec (and export is about pushing what we have), a
colonless refspec A is a short-hand for A:A, so the traditional
git fast-export master
can be thought of, in a new world order with a patch that lets you
do a ref mapping, a short-hand for an identical mapping:
git fast-export master:master
It follows that the syntax naturally support
git fast-export refs/heads/master:refs/heads/foobar
I would think.
That approach lets you express ref mapping without a new option
--refspec, which goes contrary to existing UI for any commands in
Git (I think nobody takes refspec as a value to a dashed-option in
the transport; both in fetch and push, they are proper operands,
i.e. command line arguments to the command), no?
I think that is much nicer for the simple cases, but how do we handle
more complex rev expressions? One can say:
git fast-export master ^origin
or even:
git fast-export origin..master
The "^origin" is not a refspec, and finding the refspec in the
dot-expression would involve parsing it into two components. I think you
can come up with a workable system by parsing the arguments as revision
specifiers and then applying some rules. E.g., a positive ref "foo" is a
refspec "foo:foo", but negative "^bar" does not impact refspecs at all,
and the same rules are applied for "bar..foo". There is a syntactic
conflict where "foo:bar" would be interpreted as a tree:path by the
revision code, though, whereas in this context it means a refspec.
So I think it is possible to go that route (and perhaps preferable,
even, because it keeps the simple and common cases easy for the user),
but the implementation is not as simple as just treating the arguments
as refspecs.
-Peff
On Wed, Nov 6, 2013 at 3:00 PM, Junio C Hamano [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
On Thu, Oct 31, 2013 at 12:26 PM, Junio C Hamano [off-list ref] wrote:
quoted
Felipe Contreras [off-list ref] writes:
quoted
+test_expect_success 'use refspec' '
+ git fast-export --refspec refs/heads/master:refs/heads/foobar master | \
+ grep "^commit " | sort | uniq > actual &&
It feels somewhat redundant that you have to twice say that you are
pushing your "master", once with --refspec and then the branch
name. Is this the best we can do?
As this has been discussed before and no other solution came forward, yes.
We need to take that "no other solution came forward" with a grain
of salt. After all, this is your itch, and if nobody was interested
in helping you (which I think that we both understand entirely
plausible, given the recent history), it only means you didn't think
of any other solution.
Thinking is easy, the problem is not thinking of a solution, the
problem is actually doing it. I think we should end world hunger. What
a great idea!
I didn't think things through, but at the external UI level, I see a
possibility of a nicer way to express the above.
You already said that before.
Talk is cheap. Show me the code.
--
Felipe Contreras