Jeff King <peff@xxxxxxxx> writes: > 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. I forgot about the ranges, but thinking about it further, I think what we really need to worry about is the positive end. git fast-export origin..master is (by the usual definition of A..B range) the same as git fast-export ^origin master If we realize that the bottom ends of ranges do not participate in the "update the ref at the receiving end" phase of object/history transfer at all, that command line can still be thought of as a short-hand for git fast-export ^origin refs/heads/master:refs/heads/master That is, anything negative is used only to specify the bottom of the range, and positive ones (e.g. 'master' in both of your examples) tell us what ref to update in addition to where the history ends. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html